How I Think About Product Decisions

Most product frameworks fail for the same reason: they start with solutions.

Someone has an idea. It goes on the roadmap. The team builds it. Six months later, nobody can clearly explain how it moved the business forward. The feature shipped, the metric didn’t move, and everyone quietly moves on to the next thing.

I’ve seen this happen at every company I’ve worked at. And it happens because the process started in the wrong place.

Start with the goal, not the solution

The framework I keep coming back to is GIST, developed by Itamar Gilad. Goals, Ideas, Steps, Tasks. The order matters more than anything else in it.

You start with a goal. A real, measurable goal that the business actually cares about. Not ‘improve the product’ or ‘increase engagement.’ Something specific: reduce churn by 15% this quarter.

That single goal does something most roadmap processes never achieve: it aligns every team around the same outcome while giving each team the freedom to find their own path to it.

There’s another problem that goal-first thinking solves, one that doesn’t get talked about enough.

Imagine spending weeks writing a detailed PRD for a churn reduction initiative. You’ve done the research, mapped the solution, estimated the impact. You present it to leadership. And they look at you and say: ‘Who told you our goal was to reduce churn? We’re trying to enter a new market right now. We need you focused on that.’

That conversation is demoralizing, wasteful, and entirely avoidable.

When you start with goals, you start with alignment. Before a single idea is explored, before a single line of a PRD is written, you know exactly what the organization is trying to achieve and why. Leadership has signed off on the destination. Everything that follows is in service of something they’ve already agreed matters.

The PRD isn’t the starting point. The goal is. And that changes the entire dynamic between product and leadership.

One goal, five different paths

Take ‘reduce churn’ as the goal. Every team in the company can work toward it, but they’ll do it differently, and that’s exactly right.

Engineering looks at churn data and sees that performance issues correlate with cancellations. They focus on optimization. Slow load times, broken workflows, reliability problems. That’s their path to the goal.

Product looks at support tickets and sales call notes and identifies features that customers expected but didn’t find. Missing functionality that’s pushing people out. That’s the product team’s path.

Sales notices that a segment of churning customers cited pricing as the reason. They work on packaging and discount strategies for at-risk accounts.

Customer support sees that churning customers often went silent before cancelling, never reaching out for help. They build proactive outreach workflows for accounts showing early warning signs.

Marketing realizes that churning customers had lower engagement with communications than retained ones. They increase touchpoint frequency and relevance for at-risk segments.

Five teams. Five different workstreams. One goal.

None of them needed to coordinate their solutions with each other. They just needed to agree on the destination. GIST creates that shared destination while leaving room for each team to bring their own expertise to it.

Why ideas come second

The reason most roadmaps fail is that ideas come first. Someone proposes a feature, it sounds good, it gets prioritized. The goal it serves is assumed rather than defined.

In GIST, ideas are the second layer. They only exist to serve the goal. An idea that doesn’t clearly connect to a goal doesn’t belong on the roadmap, no matter how interesting it sounds.

This sounds obvious but it changes everything in practice. When a stakeholder comes to me with a feature request, the first question isn’t ‘can we build this?’ It’s ‘what goal does this serve, and is that goal something we’re currently prioritizing?’ That single filter eliminates a huge amount of noise.

Ideas that survive that filter then get broken into Steps, which are experiments and milestones rather than fixed commitments. This is where GIST diverges from traditional roadmapping most sharply. Instead of committing to shipping a full feature, you commit to testing whether the idea actually moves the goal. Steps are designed to be validated quickly, before the full investment is made.

Tasks are the execution layer. The actual work that needs to happen to run the experiment or deliver the step.

What this looks like in daily practice

The framework isn’t a document you fill out once. It’s a way of thinking that shows up in every product conversation.

When I’m in a planning meeting, I’m asking: what goal are we working toward, and how does this idea connect to it? When I’m reviewing a roadmap with leadership, I’m showing goals first and solutions second. When I’m working with engineering, I’m making sure they understand the outcome we’re trying to achieve, not just the feature we’re building.

That last part matters more than it might seem. Engineers who understand the goal can make better technical decisions. They know when a shortcut might compromise the outcome. They know when a different technical approach might serve the goal better than what was specified. Giving them the goal, not just the task, makes them better contributors.

The honest limitation

No framework works in every situation. GIST is most powerful when you have a clear, measurable goal and enough organizational alignment to actually work toward it together.

In companies where goals are fuzzy, where teams are siloed, or where leadership changes direction frequently, the framework helps surface those problems rather than solve them. Which is still useful. Knowing that your goals are unclear is better than pretending they aren’t.

What I’ve found is that the discipline of starting with goals, even imperfect ones, consistently produces better outcomes than starting with ideas. Not because the framework is magic, but because it forces the right conversations earlier, before a team has spent six months building something nobody needed.

That’s the shift. Start with where you’re going. Everything else follows from there.