Choosing What Deserves to Be Built
Product lead Lena Ortiz on resisting the loudest request, noticing the real constraint and making better bets with a small team.
The hardest product decisions rarely arrive as a clear choice between good and bad. They arrive as three reasonable ideas, one tired team and a deadline that makes certainty feel urgent.
Transcript
Edited lightly for clarity and length.
You have said the most expensive product mistake is not building the wrong thing. It is learning too late that nobody agreed on the problem. What does that look like in practice?
It looks like a team moving quickly with five different definitions of success. Design is fixing confusion, sales is trying to close an account, engineering is reducing risk. Everyone is competent. The work still pulls apart.
How do you slow that down without turning discovery into a ritual?
I ask for one sentence: “If this works, what becomes easier for whom?” Not a deck, not a metric tree. A plain sentence. If we cannot write it, we are not ready to discuss solutions.
“Roadmaps become honest when every item has to compete for the same scarce week.”
Teams often say everything is a priority because the requests come from important customers. How do you handle the politics?
First, I stop pretending priority is a property of the request. It is a choice we make in context. Then I put the tradeoff in daylight: doing this means delaying that. People become much clearer when the cost has a name.
What evidence changes your mind?
Repeated behavior beats stated enthusiasm. I would rather watch four customers build the same awkward workaround than collect forty votes on an ideas board. Workarounds have a cost, which makes them credible.
Where does intuition belong? Product leaders are often hired because they have judgment, then told to validate everything.
Intuition is a starting position, not a verdict. Good judgment helps you choose the cheapest useful question. It should make the learning sharper, not exempt you from learning.
Do you have a favorite way to test an idea before code?
Offer the outcome manually. If we think a weekly briefing will help managers, we write five of them by hand. The work teaches us what data matters, how people respond and whether the problem returns next week.
What signals tell you to stop?
When every new explanation becomes more elaborate. Strong ideas usually get simpler as we learn. If the theory needs another exception after every conversation, we are defending it rather than testing it.
How do you keep a small team from feeling like a list of things it did not ship?
We review decisions, not output. What did we learn? Which risk did we remove? What did we consciously leave alone? A good month can include deleting a project before it becomes six bad months.
What question do you want listeners to take into their next planning meeting?
Ask: “What would we need to believe for this to be the best use of our next two weeks?” Write the answers down. The riskiest belief is usually obvious once it is no longer hiding inside the roadmap.