How a simple Product spec can unify your company and make your product a success

Ken Sandy

As an Aussie-expat based in San Francisco, I briefly took a passing interest in baseball. One of the many, many statistics leagues track is called a batting average – the ratio of times a batter actually hits the ball into play. The best batting averages top out in the mid 30% range. Getting up to that level puts you in elite company. Imagine if product management was like this. What if 30-40% of what we delivered was in-play, let alone a home-run, and the rest slipped by to the catcher and we struck out? Presumably we wouldn’t last very long in our roles!

But are we doing better?

Often we act with such certainty, bordering on arrogance. We create and publish roadmaps packing quarter after quarter with sizeable initiatives. We write lengthy market and product requirements detailing the solution we want, “supported” by overly ambitious business cases. We pitch these and make promises we hope we can keep to senior management. We’re stewards within our organisations charged to deploy scarce company-wide resources (yes, engineering, but we also profoundly impact where people across the business spend their precious time). We owe it to our organisations to operate with more humility and openness to learning and adapting. 

To be right more, realise you could be wrong

We need to boldly recognise that at any point in our discovery and development cycle, we’re not really sure-sure. Okay, we might have conviction and a body of evidence to support that we’re on the right track, but do we know with certainty that:

  1. What we’re working on is the next highest-priority problem worth solving?; and
  2. Whether the solution we’ve defined is the most effective to sufficiently address the problem?

As intelligent, ambitious and excellent problem-solvers, I’ve observed many product managers short-circuit quickly into solution-mode; prescriptively defining product requirements they believe will address a need. A need that they may not yet have fully understood. Too early not only risks working on the wrong solution for the wrong problem but fails to motivate and tap the full capacity of their teams. A collaborative solution, arrived at iteratively and with frequent validation, is likely better than anything they can come up with by themselves.

The benefits of a top-down specification framework

Operating differently starts with how you capture and communicate the problem you’re interested in solving. By focusing on the problem first you can establish an idea’s priority and clarify target outcomes. You can better align stakeholders behind these decisions. You can effectively focus and motivate your team towards a common goal, allowing specific solution requirements to emerge as you unleash your team’s creative juices on the problem. You can be wrong and rapidly adapt.

An effective tool is the top-down specification* framework. My top-down spec framework includes the following attributes:

  1. Hypothesis – This is the central notion that we wish to explore. It should be of the form “We believe THIS because of THAT and if we do THIS-THING we will achieve THAT GOAL”. By stating as a hypothesis, you explicitly communicate that you’re open to learning and shed any personal psychological attachment to being right or wrong. And because your hypothesis might well be wrong, it encourages tight scoping of any solution, constant challenge and frequent validation.
  2. Job-to-be-done – Why will your customer be more likely to buy your product or service if you do the thing you are proposing? Who is the actor and their trigger, the action (what they would like to achieve) and why is this important to them? By orienting the team around the customer and their goals, many alternative solutions become possible.
  3. Prioritisation score – Why is this a priority now, compared to other things we could be doing? A business case in isolation is always easy to build, but not so much when you’re forced to evaluate relative to other opportunities. Settle on a framework such as RICE or ICE, theme-based scoring, or whatever works for your organisation so long as it is consistently applied. Any level-of-effort estimates must be kept high-level at this point otherwise you will trigger your engineering team and rapidly find yourself debating solutions and technologies instead of opportunities.
  4. Metrics – One primary longer-term KPI and a few (at most) leading indicators that demonstrate the customer and/or business is receiving enhanced value. The “SMART”-er the better and must be linked directly to the actions of the product and development team (and not easily influenced by things you cannot control). I usually define themes and a limited set metrics for my team to pick from. For example, an initiative’s primary metric might be to increase the percentage of new visitors to the website that register for a service. Its leading indicators might include:
    1. Reduced time to complete sign-up
    2. Drop-off at each stage of the sign-up flow
    3. Enhanced recall of value proposition by new users (a qualitative metric)
    4. Month-1 retention rate sustained at current levels (a counter-metric I don’t want to see go down)
  5. Success criteria – building upon your metrics, a list of tangible, measurable statements to know when the product has been successful or not. Each ideally has a target against some baseline and is not simply milestone driven (e.g. Launch by X date). Expect to be held accountable to these results but ensure you have an opportunity to validate as you build, optimise the product after initial deployment, and be comfortable that you may miss some entirely (okay, provided you learn from your mistakes). Success criteria might be:
    • Conversion rate increases 10% over baseline with 80% confidence (for an A|B test)
    • Onboarding of new customers takes half the time over current baseline
    • 80% of Monthly Active Users utilise feature Y at least once per month
    • The proportion of customer service tickets triggered by issue Z are reduced by 50%
  6. Supporting strata – Essential context, including an objective summary and links to additional material to help the team understand the problem space. Include (but not simply cherry pick) quantitative data (analytics, market reports, customer support stats) and qualitative research (user interviews, surveys, testimonials and quotes, user testing observations). Highlight gaps or additional analysis or research to be completed.
  7. Solution approach – You may have some ideas, or early sketches or a prototype, that will aid communication of the concept. However, anything included here must only be thought of as a high-level starting point to explore, not requirements.

In addition, I suggest including a TL;DR (“Too-Long; Didn’t Read”) exec summary at the start that encapsulates key details for quick reading. Initiative titles should also be descriptive (WHAT for WHY) – avoid the use of meaningless codenames. With the exception of the “Solution approach”, you will notice all other parts of the top-down spec are about the problem you are trying to solve.

With your top-down spec in hand, you can now engage stakeholders and your team productively while leaving plenty of space for you to collaborate on possible solutions, tightly constrain scope more likely to deliver against specific outcomes, and iterate and validate as you go – willingly changing your direction with new learnings.

Want to find out more?

  • Learn more about what makes great product specifications in Ken’s book, The Influential Product Manager – How to Lead and Launch Successful Technology Products (Paperback or eBook).
  • Learn practical, proven frameworks to deliver more profitable and successful Products in our Essentials of Product Mangement Course

* By top-down I don’t mean you or some senior person in the organisation dictates the specification. I mean in the sense that you start zoomed-out, with the core problem you’re trying to solve and the goals you’re trying to achieve. Some organisations call their specs one-pagers but they don’t mean they have to fit on one page (which is also a meaningless concept when using tools such as confluence or notion). They mean short, digestible and rich in context. Or they may mean getting everyone onto the same (one) page. Either way, you get the gist!

Ken Sandy

Ken Sandy | Author

Written by Ken Sandy, product leader, author of The Influential Product Manager, and industry fellow and lecturer at UC Berkeley, where he teaches the engineering school’s first product management course.

Product Management Training