The Looking Glass: The craft of creating

Journeys before features; how to nurture fragile ideas; when to document; and absolutely unambiguous outcomes

Hello readers!

Funny things can happen when you do something for long enough.

Maybe you started your career in tech because the offer package showed some lovely numbers. Maybe your besties and seniors from college were migrating west in droves. Maybe frontier life seemed hot and exciting.

These are not the most grounded reasons to start something, but they were my reasons.

But somewhere along the way, I fell in love with the work. Not every single element of it, of course. But enough to call it love. Even now, day by day, that love grows.

What is it, exactly, that I love?

It isn’t tech, or start-ups. It isn’t the domain I work in, like social media or consumer or SaaS or data. It isn’t the specific role, like managing or marketing or engineering.

No, it is something else: the act of creating. Sculpting what is in our control towards an end.

Because it is through creation that we discover the freedom and power in our possession.

Some moments, this feels like absolute magic to me. I hope I’ll love and do this forever.

In the meantime, enjoy these reflections on the craft of creating products.

Warmly,

~Julie

This week’s tidbits:

1. Absolutely unambiguous outcomes
2. When to document
3. Journeys before features
4. From the Archives: How to be strategic

For paid subscribers:

1. What’s blocking me from getting a job after being laid off?
2. JZ’s 10 product commandments
3. How to nurture fragile ideas

Absolutely unambiguous outcomes

If you don’t know where you’re going, you’ll wind up someplace else. — Yogi Berra

If we are not aligned on the Why? of the idea, all further conversations about the How? are wasted.

The easiest way to be in mindmeld about the Why? is to define absolutely unambiguous outcomes, meaning: after our work is done, we know exactly how to evaluate whether we got what we expected.

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. (Yes, I have used these exact words to describe many a redesign.)

Stop right there. We must have taken the wrong plane because we 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 model has 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%?

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.”

But what if we can’t predict the outcome? Should we really be pulling numbers out of thin air?

The goal of defining an absolutely unambiguous outcome is NOT that we are right 100% of the time. (Trust me, we won’t be.)

The goal is to be intentional and to state our intention. Because why the hell are you building if you aren’t trying to make something happen? Just state clearly what you believe will happen. The specificity of your numbers should match the specificity of your expectation.

Doing this helps you in 3 important ways:

1. You will probably reduce frustrating disappointments later on because someone expected something different from you
2. You will get useful feedback on whether your plans are likely to result in your desired outcome or not, which should improve the quality of those plans
3. You will learn way more from the experience because you’ll be able to clearly see whether you were right or wrong and thus avoid hindsight bias.

Be unambiguous. Live happier :)

When to document

Good documentation should in the long-run feel like taking a speed boost, not a sedative. So document when:

1. 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.
2. 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.
3. You will want to remember Why (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.

Journeys before features

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.

Make those assumptions explicit. Define the user journey before you define the feature.

1. Who is the user? — How would you classify this group of people? What do they care about? What are their habits?
2. 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?
3. 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?
4. 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?

Only after the above is as clear as the creek water from the season’s first snowmelt should we even consider the words “product spec”.

From the Archives: How to be Strategic

So you might have heard that the more you progress in your career, the more strategic you should aim to be. WTF does that mean?

Here is what I used to think “being strategic” meant:

• Setting metric goals.
• “Thinking outside the box” to come up with new ideas.
• Working harder and motivating others to work harder.
• Writing long docs.
• Creating frameworks.
• Drawing graphs on a whiteboard

As a result, I tried to do as many of the above as I could. I brainstormed! I wrote epic, sweeping docs! I familiarized myself with the language of KPIs and measurements. *check, check, check* went the boxes. See how well I was strategizing?

Unfortunately, as it turns out, I was doing the equivalent of strumming a guitar and assuming I was making music. The core problem was that I didn’t really understand what strategy was. Nobody had ever explained it to me. I figured “being strategic” was just engaging in high-level product discussions.

If you find yourself in the same boat, this note is for you.

So what is strategy?

Basically, a strategy is a set of actions designed to achieve a particular objective. It’s like a route designed to get you from Point A to Point B. A more interesting question is “what makes for a good strategy?” And for that, I subscribe to Richard Rumelt’s definition: a good strategy is a set of actions that is credible, coherent and focused on overcoming the biggest hurdle(s) in achieving a particular objective.

Let’s break that down:

• achieving a particular objective: it should be clear what success looks like.
• set of actions: there should be a concrete plan.
• credible and coherent: the plan should make sense and believably accomplish the objective. There should not be conflicting pieces of the plan.
• focused on overcoming the biggest hurdle(s): there should be a clear diagnosis of the biggest problem(s) to be solved, and the plan should focus resources towards overcoming those hurdles.

Given the above definitions, let’s look back at my original list of “strategic” actions:

• Quoting metrics or setting goals: this is certainly a part of strategy, but it isn’t enough. You also need a credible plan. Saying “our strategy is to set more aggressive goals” is the equivalent of writing bigger checks and not having an real bank account tied to them.
• Coming up with new feature ideas: if you don’t know the problem you’re trying to solve, it doesn’t help to brainstorm a bunch of solutions. This is like blurting out an answer on Jeopardy before you’ve heard the question.
• Working harder and motivating others to work harder. Working hard is great, but don’t confuse motion for progress. Assuming that working harder is the answer to winning is like assuming thoughts and prayers can solve climate change.
• Writing long docs: could be strategic, but depends on the content. Beware of long, sprawling epics. Good strategies are usually simple, because executing a highly complex plan across dozens or hundreds of people tends to not work well.
• Creating frameworks: frameworks can help explain concepts, but they are not a plan. Having good frameworks is like having a clear map. You still need to chart a path.
• Drawing graphs on the whiteboard. May look impressive but is probably classic bad strategy: a lot of jargon and fluff, a lack of real substance.

Okay great, you say. Nice definitions. But the question still remains: what should I do if I want to be strategic?

Here is the secret sauce: do more of the following three tasks.

1) Create alignment around what wild success looks like.

This is self-explanatory, but hard to do in practice. As a litmus test, ask yourself…

Continue reading the rest on Medium

Below are 3 more pieces for paid subscribers:

1. What’s blocking me from getting a job after being laid off?
2. JZ’s 10 product commandments
3. How to nurture fragile ideas

Become a paid subscriber today to support my public writing habit and to keep me well hydrated and fed with coffee, sparkling lychee water, and leek tarts.

Or! Refer folks to subscriber to The Looking Glass to earn months of paid subscriptions (3 referrals = 1 month, 12 referrals = 3 months, 25 = 6 months)

Refer a friend

Read more