Software product management: building products that last

The most expensive decisions in software product management happen before the first line of code exists. Still, most teams start at the other end: set up the backlog, write tickets, plan the sprint. Building starts on day one, deciding happens later, if at all. The ritual looks professional and still runs backwards.

The backlog feels like progress: new tickets every week, something shipped every week. The roadmap fills up before the direction exists. But speed without direction is no virtue, the team just ships past the customer faster. And the situation is coming to a head: AI made building cheap. Code appears in hours instead of weeks. That shifts the bottleneck to where it always belonged: deciding what gets built and what doesn't.

This page orders exactly those decisions, from positioning to scope to organisation, and collects all articles on the product side. Written for product leaders, founders and executives in B2B software companies who have to decide where the scarce building time flows.

I work at the intersection of product, GTM and AI. GTM stands for go-to-market, meaning the path your product takes to the customer. Right now I'm helping build Teklens, a software that works inside product teams. So the questions on this page aren't theory for me, they're my weekly routine: what to build, what to cut, what to measure.

What you'll learn

• The three questions that carry every product decision: for whom, which problem, measured how.
• Why positioning comes before code and how to test it in one sentence.
• How narrow a first version may be and what deliberately doesn't get built in the first 90 days.
• How to recognise product-market fit measurably and what AI agents change about building products.

Good products come from clear decisions, not from more features

Software product management means deciding what gets built, for whom and why, and making sure those decisions hold up in daily work. That's the entire thesis of this page. Not more features, not more process, not the next framework, but clear decisions that survive the first loud customer wish. The rest of this page is the evidence, decision by decision, up to a measurable finish line.

What makes good software product management?

Clear answers to three questions: who are we building for? Which problem do we solve? How do we measure success? If you can't answer each of the three in one sentence, you're building on suspicion.

The third question is the most uncomfortable one. Success doesn't mean downloads or shipped features, but for example: customers use the product every week and renew the contract. Only a measurable criterion turns a product idea into a testable bet.

Good product management also says no more often than yes. Every feature costs three times: building it, maintaining it and explaining it. The most important skill is therefore not prioritising ideas but cutting them. And the answers have to survive daily work: a strategy that tips over at the first loud customer wish never was one. The three answers belong on one page, visible to the whole team, not in a strategy document nobody opens. Every new feature idea has to measure itself against those sentences, otherwise the loudest voice decides in the end.

Why does the product start before the code?

The most important product decisions happen before the first line is written. Who is the customer, what is the problem, why are we the right answer? That's positioning work, described in the guide to B2B product positioning.

Positioning means customers instantly understand why your product is right for them. If it's missing, it takes revenge twice. The team builds features for everyone and no one, and sales explains a different product to every prospect. Technically strong DACH companies especially tend to underrate this work, because it doesn't feel like work. A simple test: explain your product in one sentence, without the company name. If the sentence fits ten other vendors, you don't have positioning, you have a description.

And because a product only lives if it reaches the market, building and marketing belong together as a duo, as in the article on product marketing and product management. One team builds the product, the other brings it to customers. How well the two play together decides your growth.

How narrow can the first version be?

Narrower than most people dare. The most common product mistake is megalomania in scope. My counter-position: a SaaS product in 90 days, narrow, honest, shipped. Not everything you'd like, but the part customers pay for.

Just as important is the list of what does not get built in the first 90 days: no role and permission system, no integrations for hypothetical enterprise clients, no admin dashboard, no multi-language support. All of it can come later, once a paying customer demands it. Until then it's dead capital you have to maintain. The effect of narrowness is double: you ship earlier, and you learn earlier. A customer who actually uses a narrow version tells you more about your product than ten workshops about a big one.

Part of that is the honest question whether you want a product business at all, or an agency, see Service agency vs software product. That fundamental decision belongs in the chapter on entrepreneurship, because it shapes everything that follows.

Do you need a framework like the Spotify model?

Almost certainly not. Copied org models fail because they lack the context they grew out of: the company size, the culture, the problems of that era. Why the famous model of squads and tribes, meaning small autonomous teams and groups of such teams, won't work for you is in The Spotify model won't work for you.

And with small teams plus AI helpers you don't need it anyway. The coordination problems such frameworks are meant to solve only appear with many parallel teams. Stay below that for as long as you possibly can. A small team with clear responsibilities beats the rebuilt structure of a corporation.

Software product management in practice: first steps and common mistakes

How to start without spreading yourself thin:

• Answer the three questions in writing: for whom, which problem, measured how.
• Phrase the positioning in one sentence before you plan features.
• Cut the first version down to what a customer pays for today.
• Define the finish line measurably, for example with Hendrikse's three tens, more on that in a moment.
• Learn the basic technical terms. You don't have to code, but you should be able to place the basic terms. Cloud-native, IaaS, PaaS and SaaS explains the cloud world in plain words.

The common mistakes are the reversals: building without positioning, because building feels more productive than thinking. Steering the roadmap by the loudest customer instead of the ideal customer profile. Copying org models instead of solving the actual problem. And feeling product-market fit instead of measuring it, until the money runs out. Add a quiet mistake: ignoring the technical foundation until it makes itself heard. If you can place the basic terms, you understand what slows your team down and what carries it.

The measurable finish line: product-market fit, and what AI changes about it

To close, the two heaviest arguments: a finish line you can measure, and a shift that's hitting every product organisation right now.

How do you recognise product-market fit?

By numbers, not by feeling. Product-market fit means your product solves a problem so well that customers pay and stay. Stijn Hendrikse makes that finish line measurable in T2D3: product-market fit is reached when, among other milestones, 10 paying customers, 10 public references and 10 new customers via referral stand.

Feeling deceives you systematically. Prospects are polite, pilot customers praise without committing, and a full calendar feels like demand. Hendrikse's three tens are incorruptible: paid, publicly endorsed, referred. Only when strangers carry your product forward on their own does it truly carry. Hendrikse writes from a US SaaS context with investors behind him. His checklist still works for any capital structure, because it only counts what customers do voluntarily: pay, refer, stand up publicly.

Behind it sits a maturity model with a fixed order, like bases in baseball: first the first sellable version of the product, then product-market fit, only then scaling. No base can be skipped. Try anyway and you'll go back later to repair. For your product management that means: before the finish line, learning counts, not expansion.

What does AI change about software product management?

Code became cheap, decisions and context became expensive. The way of working itself is changing fundamentally: AI helpers write code and work inside the team, if you lead them. Product management gets more important through this, not less.

What that means concretely is shown in From vibe coding to agentic engineering and Agentic product engineering: from 30 to 3. Freestyle coding with AI left a hangover: insecure code, slower teams. What matters now is leading the helpers instead of trusting them blindly. And work that used to need a whole product organisation is done today by a small team with agents.

Leading here means providing context. A task is only well described when a human and an AI helper can run it without questions. What such a work order looks like is in the anatomy of a GTM ticket. Small teams plus agents replace yesterday's squad structures. For team planning that means: instead of copying org models, describe work so it becomes delegable, to humans and to agents alike. That's the new core competence in product management. More on how automation and product work fit together is in the hub on B2B automation and AI.

Deciding instead of stacking: what remains

✅ What shines: The three questions cost nothing and work immediately. A team that can answer for whom, which problem and measured how in one sentence each makes better decisions from tomorrow on, without a single new tool.

❌ What doesn't shine: Clear decisions feel slower than building. Cutting produces no demo, and a no looks like nothing in the sprint review. You only sustain that rhythm if leadership backs it.

⚠️ Warning: The biggest trap is cheap code. Because AI makes building nearly free, scope grows faster than anyone questions it. Build without positioning today and you make the old mistake at machine speed.

Which closes the loop to the opening: the most expensive decisions still happen before the first line of code, only today every decision is followed by more code than ever. The backlog never was the right starting point, and now it isn't even the bottleneck. If you want notes like these on a regular basis, subscribe to my newsletter.

You'll find all product-side articles below, each described in plain language.