Time to do it twice

A friend recently shared a quote – “How come we don’t have the time to do it right but always have the time to do it twice?”

It has my vote to be framed and put on the wall of any room where folks get together to plan their product roadmaps.

In these rooms, we often find ourselves in positions where we need to make trade-offs that benefit the short term over the long term.

But, these decisions almost always result in rework in the medium term. And, when it arrives, rework doesn’t allow for any other option.

So, for the next time we find ourselves in such a discussion, here’s to remembering that they’re better off being the exception rather than the rule.

The Walkman decision

There’s a great story about a decision Sony made when they shipped the legendary Walkman.

Against the advice of market research, Sony’s co-founder had asked the engineering team to build a portable music player that would ease the boredom on long flights. The engineers then came back with what could only be termed a product manager’s dream – for nearly the same amount of effort and cost, they were able to add an additional feature – a record button – to this cassette player.

But, to their dismay, Chairman Akio Morita asked them to remove the record button.

By reducing the device to serve a single use case, he eliminated any potential user confusion. In the same way McDonalds removed cutlery from restaurants to make it clear how they wanted customers to eat their burgers, Sony released the Walkman with a lower range of functionality to give them the highest chance to change customer behavior.

And change behavior they did.

(H/T: Alchemy by Rory Sutherland)

The story of Sandwich

John Montagu was a consummate card player who didn’t like meal interruptions while playing his favorite game of cribbage. So, it is said that he asked for veal stuffed between two pieces of bread to make it easy for him to eat while playing.

As John Montagu was also the Earl of Sandwich, others started asking for the “same as Sandwich.” And the rest, as they say, is history.

For when we find ourselves stuck in discussions about building for the “average” user, it is worth reminding ourselves that the sandwich, like many innovations, happened on the edges thanks to a passionate early adopter with a weird request.

(H/T: Alchemy by Rory Sutherland – a fantastic read)

Skyspring Hotel New York

Someone we know in India received an job offer from an acquaintance in the Middle East to work at a Skyspring hotel in New York. They needed to front $600 for the visa and he’d received instructions via an email.

They come from a modest background (his mother is a cook) and she asked my mother to help check if this was a real job – $600 is a lot of money after all. The “pay upfront to get this job” rang all kinds of alarm bells. But, it was hard to dismiss it outright since it came from someone they knew.

And, it didn’t help that Google had a very convincing looking card show up on search.

Of course, it all unravels the moment you spend more than a minute investigating. The hotel has no trace on Tripadvisor or Booking.com and the phone number doesn’t work. The email has a few typos (why do scammers not get that right?), was sketchy on details of the work visa, and it came from a questionable looking “@consultant.com” email address.

All in all, it was more sophisticated than the traditional Nigerian prince scam and it could have fooled someone who wasn’t discerning. I think the Google card was the most convincing piece of the scam and I couldn’t find a way to flag it on my phone (I found it on my laptop and did so).

It did get me thinking about how important it is to design products with scam/bad actor use cases in mind. It isn’t enough to just think of the happy path.

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.

The trim dashboard

One of my favorite product experiences as a user in the past year has been with Trim. Their value prop is simple – you connect your cell phone and cable accounts – and they negotiate a better rate every few months.

As they serve thousands of customers, they have the data at hand to negotiate effectively on your behalf. So, I find myself smiling every time I receive a heads up text from them that says “we’re negotiating on your behalf.” Their latest negotiation (not yet added to the dashboard) seems to have saved me another $180 for the year on my Comcast bill.

And, that’s on top of the ~$600 in savings they’ve negotiated in the past year. I’m happy for them to take 33% of this as revenue as it still means $400 in savings.

Their dashboard, thus, is a weekly reminder of the value they’ve added to my life.

As someone who attempts to build valuable products for a living, the Trim dashboard is a great example of this gold standard user experience – the ability of a product to clearly demonstrate the value it delivers.

Writing for executive audiences – a 3 step process

A note for new subscribers: 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. And, I hope you find that to be the case as well…

We’ve covered the following topics so far in this series –

  • Defined the role of a product manager and outlined the 4 key skills required to do the job – problem finding (solving for value), selling, problem solving (solving for usability and feasibility), and building effective teams.
  • 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 for their users/customers. Today’s post will focus on a core piece of this sales and marketing toolkit – writing for executive audiences.

Why is writing for executive audiences a core piece of the sales and marketing toolkit? As IC product managers, many of our opportunities to persuade tend to come from sharing our thought process in writing with internal stakeholders (typically executives in the product management org)- via strategy documents, issue investigations, product specs, and email exchanges.

I’ve intentionally picked an internal audience as the focus because that’s where the biggest challenges tend to lie. When the organization is aligned on the problem that is being solved, it is much easier to build and sell a cohesive solution to users/customers.

For the purpose of today’s post, I’m going to assume most of the longer form writing happens in long form memo-style documents versus PowerPoint presentations. I’m also not going to focus on product specs as that will form the core piece of skill #3 – Problem Solving – and will be covered in our next post.

So, today’s note will be focused on strategy documents, issue investigations, and email exchanges for executive audiences.

The 3 step process. My suggested approach to writing (and speaking) experiences is to work through the 3 parts of the process – 1) Content – start early and write down everything you want to convey, 2) Structure – rewrite your content and make it easy to consume with a logical flow, and 3) Delivery – tailor the final delivery to your audience.

1) Content – start early and write down everything you want to convey. Block 2 hours on your calendar as soon as you know you have a document to prepare and write down everything you want to convey. Don’t worry about logic or structure – simply put all your ideas down in one place.

As simple as this sounds, there is a common pitfall in this process that I’ve seen myself and others fall prey to – postponing the act of generating content because of a desire for the perfectly structured first draft.

If you are most people, your first draft is going to suck. That’s expected. Procrastinating at this stage ends up becoming very expensive because most docs require multiple revisions. Great documents are rarely written in a day. They are also rarely written by blocking out 2 days prior to your review. Instead, the optimal creation process looks something like this.

2) Structure – rewrite your content and make it easy to consume with a logical flow.

“For the average business or professional writer, producing more literate memos and reports does not mean writing shorter sentences or choosing better words. Rather, it means formally separating the thinking process from the writing process, so that you can complete your thinking before you begin to write.” | Barbara Minto, The Pyramid Principle

Now that we have followed Barbara Minto’s advice and completed our thinking in step 1, we are ready to begin to write. The key at this stage is to pick a logical structure that will help convey your ideas. There should be plenty of examples of good structure around you – just look to prior strategy docs or issue investigation docs that have been well received.

Figuring out a structure should not be rocket science. For example, a good issue investigation doc follows a version of – 1. What is the problem?, 2. Where does it lie?, 3. Why does it exist?, 4. What could we do about it?, 5. What should we do about it?

Similarly, most good product strategy docs follow a version of – 1. Problem statement (user/customer need), 2. Size of opportunity if the problem is solved, 3. Our hypothesis and key assumptions, 4. Principles, 5. Strategy (where do we play?, how do we win?), 6. Roadmap / Tests to validate key assumptions, 7. Open questions/Areas we need help.

The challenge in this step (at least in my experience) isn’t finding a good structure – instead, it is in building the discipline to keep iterating on our original draft. Again, Barbara Minto puts it nicely –

“Once you put ideas in writing, they take on an incredible beauty in the author’s eyes. They seem to glow with a fine patina that you will be quite reluctant to disturb.”

The first draft is simply the act of laying down our thought process. The act of structuring involves breaking up with that first draft and rewriting to make it easy to consume.

3) Delivery – tailor the final delivery to your audience. All the work we put into writing and speaking is to persuade our audience. So, this 3 step process involves moving from “what do I want to say?” to “how can I best make my case to the audience?”

Great sales and marketers understand that their success is dependent on their understanding of their audience. When they understand their audience, they can create the sort of resonance in their messaging that leads to action. So, as product managers, this means doing the work to get to know our audience and asking ourselves – Do you understand how to build an argument that will resonate with your key stakeholders?

If the answer is no, we need take the time to meet with our stakeholders and understand them better.

This content-structure-delivery process applies to presentations and emails as well. While we’ve focused on the creation of a document, this process works just as well for preparing a presentation, answering an email, or taking questions at the end of the presentation.

I had shared an illustration recently with a few folks on “good, better, best” for answering exec questions (in Star Wars lingo of course :-)).

As you’ll see, the same process holds. If you are responding to an email, write down your thoughts, rewrite in a logical structure that focuses on clarity over completeness, and seek to deliver the message in a way that anticipates any obvious follow up questions.

You have less time to work through this process in a live Q&A – but, the same idea holds -> understand your audience’s intent when you answer questions. And, if it is unclear, clarify.

While the purpose of the structure stage is to build a logical argument, the purpose of the delivery stage is to transcend logic and create emotional resonance.

While logic will help lead our audience to the conclusions we derive, it is emotions that will help us persuade our audience to take action to support us in our quest to build better experiences for our users/customers.

A career and life sidebar: As you’ve probably noticed by now, this approach is applicable well beyond exec communication. This post could just as easily have been called “Writing clearly” or “Communicating with clarity.” But, in the spirit of focusing on emotional resonance, I have come to realize that the term “Exec Communication” resonates better. :-)