Gathering inputs: life cycle, market, customers, stakeholders

A roadmap is only as good as what goes into it. Before the vision and the objectives come the inputs: what you know about the product, the market, the customers and the people around you. They come from four sources: where the product is in its life, the market around it, its customers and its stakeholders.

Feature requests are inputs too, but thin ones: they're opinions about solutions. Real inputs explain why those requests exist.

At CatChow, the first roadmap page reached Ian, the CEO, and he liked it. But the board meets on the 14th and will ask why: why these two objectives, why now, and where the numbers come from. Some of the numbers came from staring at the spreadsheet for a long time.

So for every number on the roadmap, note its source: which data, from whom, how recent. A number with a known source can be defended in front of a board, or corrected if the source turns out to be weak.

The first input is the product life cycle. The classic model has four stages: introduction, growth, maturity and decline. Some models add a fifth, expansion into a nearby need. The labels matter less than the question: what does this stage ask of the roadmap?

• Introduction: almost everything is a guess, so the roadmap is mostly a list of things to learn: what customers will use and pay for.
• Growth: scale what works and fix what breaks as volume rises.
• Maturity: keep the customers you have, protect margins and reach into nearby needs.
• Decline: plan an honest exit, with migration, support and clear dates for customers.

Naming the stage explains why some themes come first. A roadmap full of acquisition experiments makes sense for a new product and looks odd for a mature one whose money leaks through churn. Write the stage down at the top of your inputs: it answers “why this?” before anyone asks. The stage also sets how far ahead the roadmap can sensibly look, which matters when module 3 picks the timeframes.

Parts of one company can sit at different life cycle stages at the same time, and each part asks something different of the roadmap. CatChow is a clear case. The subscription has had customers for years, and keeping them now matters more than signing up new ones: that's maturity, or close to it. The vet clinic channel is young: 54 clinics, and every order still goes through a phone call. That's growth, and it needs different work.

That's why Ian has two objectives: one part of the business has to keep people, the other has to grow.

This is also how you answer the board's “why these two?” in three sentences, each built on an input:

• Stage: the subscription is maturing, so growth depends on keeping subscribers; the clinic channel is young and growing.
• Money: in a mature business, keeping a subscriber is cheaper than finding a new one.
• Market: vets choose prescription diets, so clinics decide which brand pet owners buy.

The market around a product changes what's worth building, and it's more than competitors. It's the whole ecosystem: who else serves your customers, who you depend on, and how the business makes money. That's why it matters even to engineers like CatChow's tech lead, Lucy, who'd rather know what to build than who the competitors are.

For CatChow that means pet shops, supermarkets and online marketplaces, and the clinics themselves. Clinics are both customers and a channel: a vet chooses the prescription diet, so the clinic decides which brand a pet owner leaves with. That's why the channel matters more than its size suggests, and no feature list would tell you so.

Then the money: who pays, what it costs to serve them, where the margin is. A one-page sketch of the business model is enough. Without it you'd be guessing which problems are worth solving.

The market also moves. If a supermarket chain launched its own cat food subscription, the Next column could change overnight.

In B2B the buyer and the user are often different people, and they need different things: the buyer decides on renewal, the users decide whether the product actually works. CatChow's first clinic deal shows it. PurrPoint's procurement manager agreed to a pilot in two clinics, starting in November, instead of an April date. She signs the contract, but she won't place a single order; the clinic admins do, every week.

So whose behavior shows whether the clinic theme is working? The users': fewer phone orders, fewer stock-outs. The buyer, the account manager and the board see the result only later.

For cat owners buyer and user are mostly the same person, though strictly speaking the end user is the cat, and cats have strong opinions about taste. Beyond buyer and user, list the roles (what each person does with the product) and the segments (groups with different needs: new owners, long-term subscribers, partner clinics).

The fourth source is stakeholders: anyone who shapes, funds, builds, sells, supports or depends on the product. Each brings you something and needs something back.

Lucy brings what nobody writes in a spreadsheet: if the pilot grows past two clinics before the warehouse system is replaced, orders will start getting lost. Engineering tells you what's feasible and fragile, and needs the reasons behind the work to plan ahead. Support tells you why people call; sales, why clients sign or leave; the CEO brings strategy and budget.

Then decide how closely to work with each. A common tool is a power/interest grid: how much say someone has over the roadmap, and how much they care.

• High power, high interest (the CEO, the tech lead): work closely.
• High power, low interest (the board): keep satisfied with short, regular updates.
• Low power, high interest (support): keep informed, for example about changes before customers call.
• Low on both: check in now and then.

Putting everyone in the top box means managing nobody well.

The way you ask for input decides what you get back. “What should we build?” brings another wish list of solutions, each with its own champion, and no way to compare them; the offer from Brandon, the key account manager, of the sales team's twelve client requests is exactly that. Ask instead for each team's top problems with evidence:

• how often it happens;
• who it hurts;
• what it costs (money, time, lost customers).

Feature ideas are still welcome, with the problem they'd solve attached. That way you collect material you can merge and rank, and an idea that solves no named problem shows itself straight away.

Make the request easy to answer: a short message, a clear deadline that leaves time before the board meeting, and a word on what happens next (you'll merge the lists and share the result). People answer more readily when they know their input won't disappear into a spreadsheet.

When you merge the replies from support, sales, engineering and the data, look for repeats. Several independent sources pointing at the same problem make it probably real. At CatChow, support hears that subscribers run out before the next delivery, the cancellation survey says the same, and billing data shows churn peaking right after missed deliveries. Three sources, one problem: it goes near the top.

A problem only one loud person mentions still goes on the list, lower, with its single source noted. Volume isn't evidence: a founder who raises loyalty points at every meeting is one source, however often you hear it.

Keep the result short: five to ten problems, each with its source.

How it fits together: four sources (life cycle, market, customers, stakeholders) boil down to that short list of problems with sources. It feeds the vision, the objectives and later the themes. Next, Product vision and value proposition turns it into the sentence at the top of the page.