Product planning · A practical guide

The smallest product
that completes the journey.

Choose the right starting point, define an observable outcome and give the first release a clear boundary.

An idea becomes easier to build when it describes something a person needs to accomplish. Start with the work—not with a list of technologies or a screen full of features.

1. Choose where the work belongs

If people need to discover an offer, understand it and make contact, a clear website may be the right first product. If they repeatedly perform a task on a phone, especially away from reliable connectivity, a mobile application may deserve a closer look.

If the main problem is the repeated transfer of information between existing tools, an integration or automation may provide the more direct answer. The best starting point is the one that addresses the actual obstacle with a manageable operating cost.

2. Describe a complete journey

“Record a completed job without a connection” describes an observable need. “Build an advanced dashboard” leaves the real task unanswered. Name the person, the action, the information involved and the result they need to see.

A first release should complete a useful journey from beginning to end. It may have fewer secondary features, but it should explain what happens when the action succeeds, fails or needs correcting.

3. Include the cost of running it

Software is also a commitment to updates, support and ownership. An application needs distribution and device support. An integration depends on the permissions, limits and behaviour of external systems. A website needs content maintenance and a clear contact route.

Decide who will own accounts and infrastructure. Include backup, recovery and maintenance responsibilities in the scope before selecting a technology. This helps avoid a product that is easy to launch and difficult to operate.

4. Write a brief that helps decisions

Describe the current process and the people involved. Include examples with personal information removed. Name the point where time is lost, information is repeated or an error becomes expensive.

  • Users: who needs the product and in what setting?
  • Essential outcome: what complete task must the first version support?
  • Existing systems: which tools and sources of information are involved?
  • Constraints: devices, languages, accessibility, budget and timing.
  • Acceptance: how will someone demonstrate that the agreed behaviour works?
  • Ownership: who can make scope decisions and maintain the result?

5. Make room for deliberate changes

Learning something new is part of product work. When a priority changes, record the impact and make an explicit decision about scope, time and cost. Adding every new idea to the current release can leave the essential journey unfinished.

A focused product creates a better basis for the next conversation: what is useful, where people struggle and which improvement should come next.

Turn your idea into a project brief ↗

Bring the problem.
Let’s shape what comes next.

Discuss your project