Working With Me
My knowledge of startups and innovation is based on a combination of business theory I picked up in books, experience that I’ve had over the last 10 years, and a series of wonderful mentors over the time that I’ve been in technology.
I have no proprietary claims of knowledge in the business world, but I do have a consistent and effective method of operating in high-chaos environments in order to deliver ordered, measurable results. After feeling my way through this process for many years, I’ve taken the time to codify it slightly more cleanly in the last 2 years.
Insights
All business writing flirts with cliché, but in this case I believe these three things to be true:
Design methodology is an unfair advantage when it is applied to business processes correctly, because it forces you to measure success properly.
Do things that no one else wants to do- (document a process, improve something by 1%, give tough feedback, or kill off something that is not working). Being consistent at these types of hard things improves team performance.
Meetings are for decisions.
Tools
I use three tools to achieve results in my work environment, and they’re not anything special.
A white paper format that is approximately- “purpose, hypothesis, analysis, conclusion, deliverables, thank you’s”
The Stanford D School design methodology.
Notion, or a similar structured database, to organize the process. Sometimes Sketch if its a messy thing that needs extra love.
Process and Order
1) Audit of Current Problem, White Paper
Much of the work of early stage startup leadership is understanding the difference between change and chaos. Auditing a problem is a great way of getting to the core of the issue and make sure that it is worthy of the time and attention it is about to receive, and understanding the ways that users or stakeholders are currently solving the problem.
This step concludes with a white paper that “kicks off” the process and interrogates the questions below so that everyone involved understands where things are going, and gives the team a way to see how questions and assumptions were framed on Day 1 of the project.
2) Definition of Stakeholders, Notion Database
Understanding who will be affected by the work that is forthcoming is a critical step in getting team alignment. This is a simple, important step that is too often forgotten- listing stakeholders, and understanding how communication channels will flow to these stakeholders, and if possible, gathering basic data on them.
3) Scope of Existing Solutions, Notion Database & White Paper
Typically, the problem you’re trying to solve in the world has already been solved by clever humans before you. This is a moment to analyze these solutions, get them into a database and assign them values, and then write up a white paper showing where the current solutions are at.
4) User/Stakeholder Empathy Session, D School Methodology
Oceans of internet ink have already been spilled on the virtues of the D School Empathy methodology, so I will contribute as little as possible to that vast body of water and say only this- Empathy is magic.
5) Visual Solution Architecting, Notion Database, Sketch
This is a key step to understanding the possible outcomes of a project from a visual perspective, and a great way to mark progress in a pre-solution phase- I like to literally “map” a problem, and then print it big and stick it on the wall.
6) Prototyping Solutions, D School Methodology & White Paper
This step shifts focus to solution prototypes, which can range from many small experiments to a simple prototype of something that I have high conviction around. I use the same methodology for prototyping, and when I am satisfied with a prototype or sample of prototypes, typically close this out with a “towards goal X” white paper that really helps rally the stakeholders behind the solution.
7) High Fidelity Prototype, Various
I’ll complete the prototyping phase by deploying the solution in a format that is as close as possible to the final product- and typically begin user testing in a more rigorous manner at this point.
8) Define, Build & Release Solution, Various
Phase when I’ll move from the prototype to a real-world solution, which can mean either just increasing the fidelity of a prototype until I’m satisfied, or turning that prototype over to an individual or team that can take it all the way to a final, polished form.
On release, I’ll typically manage that process with cohorts of users that are recruited in the Empathy Session phase.
9) Observe, Test, QA, Post Mortem, White Paper
From the release point, I’ll observe, test, QA, and write up a full account of the process of solution finding that allows the stakeholders to understand the process from A to Z.
From there, the documentation that has been produced is essentially done, and I’ll just combine all the previous steps to have in place the necessary docs to have this whole process understandable in under 30 minutes by anyone.
