Baking bread and writing good product specs

A note for new folks: This post is part of a monthly Sunday series on my notes on technology product management (this is what I do for a living). You might notice that these posts often link to older posts in the series on LinkedIn even though they are all available on this blog. That is intended for folks who only want to follow future product management related posts. Finally, for all those of you who don’t build tech products for a living, I believe many of these notes have broader applicability. This post, however, may be an exception because of its “inside baseball” nature. :)

We’ve covered the following in this “Notes on Product Management” series so far –

  • Role and 4 key skills: Defined the role of a product manager and outlined the 4 key skills required to do the job – problem finding (solving for value), problem solving (solving for usability and feasibility), building effective teams, and selling.
  • Skill #1 – Problem finding: We spent time working through why problem finding is the most important skill and how to approach building problem statements and hypotheses.
  • Skill #2 – Selling: We outlined why all Product Managers spend significant doing sales and marketing in their bid to drive the change they seek to make and also why learning to write for executive audiences is a valuable skill.

—

Today’s post will take us to the one of key pieces of the “Problem Solving” part of Product Management – How to write a good product spec.

In a conversation some time back, a chef explained that baking bread was among the biggest challenges he faced as a chef. He explained that every piece of bread he baked was a summation of many hours of effort and an obsessive focus on detail – all of which showed itself in the final product.

On the face of it, it seems like an easy enough task to bake a good piece of bread. But, getting it to “good” and then to “great” – that takes something else entirely. Japanese sushi chefs are known to speak similarly about rice.

And, I think product managers ought to think about product specs the same way. :-)

A Product Manager’s Bread

The ability to write product specifications is listed as a basic skill in every job posting for a product manager. Despite how commonplace it is as a skill, getting it right consistently is no mean feat.

As in the case of baking good bread, the product spec is less about the document itself and more about the work that precedes it. To understand this, it is worth understanding the costs involved in the product development process.

There are 3 important takeaways from this illustration of costs.

First, problem finding is the cheapest stage of the process. Every good product needs to pass 3 tests – value, usability, and feasibility. Of these, figuring out if the product is valuable is the least expensive part of the product development process. This is the “problem finding” stage and involves getting to a watertight problem statement and list of hypotheses that we want to test. This is typically done by combining user behavior insights and data from existing products or from lightweight tests that generally requires minimal (if any) code.

Second, the product spec is the crucial step that marks the a shift in focus from solving for value to solving for usability and feasibility. The product spec is the moment we say “yes, we have found a valuable problem that is worth building a product for.” This, then, leads to the more expensive stages of the product – designs, tech designs, development and go-to-market.

Third, the product spec, thus, is as much about what precedes it as what lies ahead. A good product spec is as good about providing clarity on the “why” behind the product as it is about the “how” (principles) and “what” (user stories).

Elements of a good product spec:

Building on what I’ve laid out above, I believe the following are the elements of a good product spec –

  • Problem Statement: User/customer problem and value of solving it
  • Hypotheses: Proposal to solve the problem
  • Riskiest Assumptions: Assumptions that we’ll test / are key to the success of our proposed solution
  • Principles: Decision making principles that will help us make trade-offs
  • User stories and accompanying acceptance criteria: Example below
  • Success Metrics: Ideally, this section is a combination of our objectives as well as the metrics that will help us measure success.
  • Designs: A link to the designs when they are complete
  • Tracking spec: Optional
  • Build + Ramp plan: A rough timeline for when we should expect to see the change in product
  • Open questions: Areas that still need to be explored/questions that need resolution before we finalize the product spec

While I expect to cover topics such as “principles” and “success metrics” in future posts, an article on product specs would be incomplete without covering user stories. There are many good resources on how to write them. My preferred format tends to be a user story followed by a few bullets that lists the acceptance criteria that articulate how the product is meant to work. Each of these bullets would have a priority (which can also be set at a story level) so we know what will get built first. Below is an example –

As a user, I want to be able to take pictures when I’m sending a message to a friend

  • P0: The user should be able to open up the camera with a single click
  • P0: Once she takes the photo, she should be able to add a description to the image before sending it
  • P1: If there is an error at either stage, she should see the following error message – “xx” – and we should receive a notification in our error log

You will find better resources on how to frame user stories and acceptance criteria on the web. The key takeaway, however, is to make sure you write them. This is a lesson I’ve learnt repeatedly – start with the user story instead of just rushing to describe the feature. Writing out the story always helps provide better clarity on the problem we’re trying to solve.

More crucially, it provides a vehicle for the team to share better ways to solve the problem and suggest better acceptance criteria. That alone makes the exercise well worth the effort.

These elements will help us fix issues and holes in our thought process faster. The sooner we fix these issues, the less expensive they are to the team and organization. That, in turn, means we can transition smoothly to the problem solving and go-to-market phases of the product development process.

3 truths about product specs

All this brings me to the final section of this post – 3 truths about product specs.

(1) A product spec is a communication tool – there is no one way to write a good one: While this post is about writing good product specs, a large portion of the post was dedicated to understanding the importance of writing them and laying out the elements of a good spec. That is because a product spec is a communication tool that ideally brings clarity and alignment within the entire product development team on building a product that is valuable, usable, and feasible.

It is natural, then, that different teams have different communication styles as a result of the personalities involved and the type of products built. For example, a highly technical back-end product will require a different flavor of spec versus the one I’ve laid out above. Similarly, a tech lead and designer who thrive on finding edge cases will need less detail on the acceptance criteria than others who don’t. Find what works for you.

(2) A great use of a product spec is to solve for value before solving for usability and feasibility. If there is one theme from all of the posts in series that you should take away, it is the importance of solving for value. Take the time to get the problem statement and hypotheses right – this is the value in good product management. If your planning process forces you to write specs in a hurry, fix that planning process (more on that in another post).

(3) Shipping a good product spec is like shipping a product – it requires iterations. Involve the entire cross functional team early in the problem finding process, use their feedback to better articulate your problem statement and hypothesis, get feedback from peers and teams who are impacted by your products, and keep iterating on the user stories till you have everyone aligned on the spec.

Good specs and great specs

I’ve repeatedly emphasized the word “good” over the word “great” with respect to product specs in this post. That’s because I’m not sure if we can ever write a great product spec – at least not off the bat.

A product spec is an artifact of the product development process that is in service of solving a valuable user/customer problem. To the extent a good product spec helps create a great product by providing the right level of clarity and alignment within the team, we can call it a great spec.

But, the meta point is that a great product spec shouldn’t be the goal. Building a great product and a great product teams are worthier goals to aspire for. Just don’t let a poor spec get in the way of that.

Growing responsibilities and scope

The default approach to growing responsibilities in organizations is often focused on two dimensions – i) breadth – i.e. broaden scope and ii) layers – i.e. add layers and build a team.

What is fascinating is that consistent personal and professional growth in the long run tends to skew in another dimension – our ability to go narrow and deep. Doing so means asking difficult questions, pushing boundaries, and demanding excellence (even when it is unpopular) over a sustained period of time.

When we demonstrate the ability to dig deep into narrow areas over a sustained period, we provide great leverage to the organization. As a result, we are trusted to broaden our aperture and hire others to provide more leverage.

The other benefit of this approach is that expansion of this sort tends to be organic and, by definition, healthy for the organization we are in. But, as it is built on trust, it doesn’t show instant results.

Instead, like most good things in life, this trust builds and compounds over time. Slowly at first. Then quickly.

Satya Nadella and bad days

I was recently reminded of a line about bad days from an interview with Microsoft CEO Satya Nadella.

He was talking about what changed when he became CEO and he said (paraphrased) – “One of the things I realized is that I can never have a bad day.” He went on to explain that the ripple effects of his bad day were too large for it to ever be an option.

It is a simple and powerful idea – one that is applicable well beyond work and the teams that we run.

We don’t control what happens to us. But, we do have options on how we respond…

Mistakes, chatter, and showing up

The more time we spend trying to build new things or get work that matters done, the more mistakes we are inevitable going to make.

I’ve come to realize that the key is to not let the chatter (both external and internal) about the mistakes and the stuff that is broken to get in the way of showing up every day with enthusiasm.

Every day, we get the opportunity to solve puzzles that involve continually prioritizing between fixing what’s broken, plugging short term gaps, and investing in the long term. We get to do this in our products, in our communities, in our families, and within ourselves.

We (and what we build) are always going to be work in progress. Once we accept that, it follows that the best thing we can do is to make the most of that opportunity and continue to earn it every day.

In the long run, it turns out that becoming is far more important than being.

Strategy and trade-offs

Good strategy involves making explicit choices that are backed by a clear articulation of the trade-offs that accompany those choices.

Articulating strategy well isn’t about listing everything required to be done to win. That part comes easy.

The challenge with crafting good strategy lies in picking the path to winning with the limited resources (and they are always limited) at hand. More often than not, that path involves investing heavily in your own strengths while doing just enough so the weaknesses don’t get in your way.

There are obvious trade-offs with that (or any) approach. But, again, if there aren’t clear trade-offs, it isn’t strategy.

Change and resistance

We cannot effect the change that we seek to make without fighting the inertia that accompanies attempts to break unhelpful habits and destroy existing patterns.

The inertia is universal – it applies just as well to changing how often we exercise to reinventing how our teams do work.

So, if you are trying to effect change and are sensing resistance, that’s just a sign that you are on the right track.

Bend vs. squat

A good friend went to a physiotherapist recently to get started on treating his back. The physiotherapist demonstrated a collection of small things he’d need to change to give his back relief. The principle underlying these changes was either to lean forward or to squat instead of choosing to bend.

His experience immediately resonated as I’d shared this in a post recently about the right way to lift weight (or a kid depending on what you do more often :-)).

When faced with picking something up from the ground, our backs readily offer to help shortcut the effort it takes to squat. But, every time we do so, we strain those muscles and, in the process, lose the leverage that comes from the stronger muscles in our legs.

The more we avoid taking this shortcut, the stronger and healthier our backs and legs will be.

There’s a life lesson in there somewhere too.

Two ways we shape culture

Every person, team, and organization has a culture – a set of norms that governs how decisions are made. Since the quality of our execution is a by-product of our decisions, our culture becomes our strategy in the long run. “This is how we do things here” becomes “this is what people like us do.”

There are two ways we shape the culture of our own self, of our teams, and organizations every day –

1. People: The people we decide to hire, fire, or promote (whether via titles or via praise) are the single biggest lever we have to shape culture. While this appears to apply only to organizations and teams, the same holds true in our life. The people we choose to spend time with and, more importantly, the people we choose not to spend time with shape our personal culture.

2. Systems/Processes: The systems/processes we create do two things at once. First, they guide and incentivize certain kinds of behavior. And, second, when done well, they provide transparency into how decisions are made. A great resource planning process, for example, clearly lays out the decision criteria. In our personal life, habits are examples of the systems we create to guide behavior and help us make better decisions consistently.

I’ve spoken to many folks who ask questions about the cultures of the teams they’re considering joining. While this is a very important question, I think it is also important to remember that cultures aren’t set in stone. Instead, like wet clay, they can be shaped.

And, as we make daily decisions (whether consciously or unconsciously) on people and processes, we play our part in shaping it everyday.