Product strategy

Product strategy for complex software.

Before the interface. We map business goals, user needs and system constraints into one direction the whole team can build against.

WHY IT MATTERS

Most products do not fail
at the screen level.

They fail because six teams held six different ideas of what the product was for, and nobody wrote the difference down. By the time that surfaces it looks like a design problem. It is not.

Strategy work is unglamorous: interviews, timing studies, arguments about scope. It is also the only part of the process that can save you from building the wrong thing well.

WHAT THIS INCLUDES

What the engagement
actually covers.

  • Product discovery

    Stakeholder interviews, existing-system audit, and a written account of what is actually true today rather than what the org believes.

  • UX research

    We talk to the people who use the thing. On site where it matters — you learn more in an hour beside someone than a week of survey data.

  • Workflow mapping

    Every step, every handoff, timed. This is where the eight-minute problems hiding behind the forty-minute complaint show up.

  • Information architecture

    How the product is organised, named and navigated, decided before anyone argues about a menu.

  • Roadmap definition

    Scoped and sequenced, with the reasoning attached so it survives the next reprioritisation.

  • Success metrics

    What we agree to measure, and the baseline we measure it against. Without a baseline there is no result later.

WHAT YOU END UP WITH

What you actually
hold at the end.

  • A prioritised opportunity map, with the evidence behind each item
  • A product direction your engineering and business leads have both signed
  • Baseline measurements, so the work can be judged honestly afterwards
  • The research itself — recordings, notes and findings, not just a summary
COMMON QUESTIONS

Asked often enough
to answer here.

01Is this worth it if we already know what to build?

Sometimes not, and we will say so. But "we know what to build" usually means one person knows. The value is in finding where that belief is not shared.

02How long does it take?

Four to six weeks for a focused product. Longer where users are hard to reach or several acquired systems are involved.

03Can this run alongside design?

It can, and often should. Discovery that stops the world for two months is rarely worth what it costs.

START A PROJECT

Have something complex
to build?

Tell us the problem. We will come back with how we would approach it — not a pitch deck.