If you don’t know where you’re going, you’ll wind up someplace else. — Yogi Berra (View Highlight)
If we are not aligned on the Why? of the idea, all further conversations about the How? are wasted. (View Highlight)
The easiest way to be in mindmeld about the Why? is to define absolutely unambiguous outcomes, meaning: after this project ships, we know exactly how to evaluate whether we succeeded or not. (View Highlight)
For example, at lunch, a colleague asks you what you’re working on. A grand redesign, you say. Coolcool, says your colleague while chomping a burrito the size of their head. What’s the redesign suppose to do?Oh, it simplifies everything, you say. Users will have a way clearer mental model of our product after this change.
Stop right there. You must have taken the wrong plane because you are continents away from giving an absolutely unambiguous outcome.
What does having a way clearer mental model of our product mean?
If we stood behind one of those creepy one-way glass walls and observed 5 users using our product after Le Grand Redesign, would we all unanimously agree Yes, clearer mental modelhas been achieved?
Obviously not. How about this then?
We will see people use our product more frequently as a result of having a clearer mental model.
That’s better. At least it’s a binary — did they or didn’t they use the product with greater frequency? But there is still fuzziness on what degree of usage we’re aiming for. Are we happy if it’s a 2% increase? Or are we looking for 20% more usage? Or something more like 200%? (View Highlight)
Examples of absolutely unambiguous outcomes:
• This new feature will ideally be used twice a month by at least a third of our most active users.
• This change will ideally increase revenue by 10% while keeping churn stable
• Users should be able to load the page twice as quickly a vast majority of the time.
• When we ask our top 10 customers, at least 8 of them will agree with this statement “This change makes the product significantly easier to use.” (View Highlight)
When to document
Good documentation should in the long-run feel like taking a speed boost, not a sedative. (View Highlight)
document when:
You anticipate needing to explain the same things over and over to multiple people. If you’re looking to get feedback from your manager, your manager’s manager, the data team, the engineers, and that adjacent growth team, it’s probably going to be faster to pass them a document they can comment on than to repeat yourself in countless 1:1s.
You want to convey technical, precise details. There is a reason why the norm for APIs is written documentation rather than Youtube videos — because it’s easier to capture the specifics in writing than via a voice-over. Give them only the latter, and you might as well be begging for repeated follow-ups.
You will want to rememberWhy (or how) did we do X?weeks, months or even years into the future. Imagine new people joining your team. Imagine someone taking over your work in 9 months time. They will probably have questions. They will want to know why you chose solution A and not B, or what’s the deal with that weird hack C. If it’s been long enough, you may not remember why unless you’ve written it down, which means you are essentially giving these people the burden of having to retrace your steps without handing them a map. Don’t be surprised if it takes them two or three times as long. (View Highlight)
Product features exist to solve a problem or fulfill a user need.
When we go straight to proposing a feature, we are picking a recipe before knowing anything about the party. We are surfing waves of assumptions. (View Highlight)
Make those assumptions explicit. Define the user journey before you define the feature.
Who is the user? — How would you classify this group of people? What do they care about? What are their habits?
What problems do they encounter? — What do they want to achieve? What are their pain points? How do they think and behave? What evidence do we have for believing this?
How will they engage with our proposed solution? — What is their conception of our solution? What is their first touchpoint with it? What’s going through their heads as they make the decision to click/tap/engage with our work? What are they expecting?
How ideally would our feature fulfill their need(s)? What is the step-by-step flow (best expressed through wireframes or storyboard) for how this feature solves their problem? What are they seeing or experiencing at each step? How do we want them to feel at each step? (View Highlight)
