Product discovery for software developers


Status: DRAFT

Working with product discovery has changed how I view programming. I’ve slowed down. I write less code. When I write code, I write code for different reasons.

Why? Coding it up might not be the hard part. Then what’s the hard part? Let me share my perspective.

Slow is smooth. Smooth is fast.

Your value as a human being is not determined by the code you write. If you don’t code now, that doesn’t mean you’re doing a bad job. A part of you already knows this. More code isn’t better.

Then, what’s valuable? That is the important question. I ask myself “what’s important now?” every morning. I don’t have a canned answer. Well, actually, I do have a canned answer. Help the people around you. But then what?

The job of good product management is to provide a good answer to “And then what?”. My answer often takes one of three forms:

  1. Work towards a valuable outcome
  2. Reduce the right product risk
  3. Create a high-leverage context for our effort.

Work towards a valuable outcome


“focus on what before how”

Reduce the right product risk


possible risks:

“focus on what before how”

Create a high-leverage context for our team effort


synthesis - “leverage”? “help your team?” metric - “am I helping others now?”

Application in the lens of the feedback-API-implementation model of development

Model - feedback loop / interface design / how does it work.

How does feedback-interface-implementation synthesize with this? How do they look together?

Some kind of conclusion / synthesis

Knowledge management? Intent management? Peter Drucker and Andy Grove come to mind.

It’s so weird that we have such strong feelings for the quality of our code. Yet — our intention, our goals are not held to the same scrutiny. In fact, they often seem accidental.