There’s a quote about The Grateful Dead attributed to legendary rock promoter Bill Graham – “They’re not the best at what they do, they’re the only ones that do what they do.”
In retrospect, I realize that we grow up with a lot of emphasis on becoming the best at what we do. There’s not enough emphasis on becoming the “only.”
And, typically, the route to that is to become very good at (and, hopefully, enjoy practicing) three or four skills that combine and complement each other.
In his book “Ready for Anything,” David Allen shares a story about being stuck at a certain level learning Karate. Try as he might, he wasn’t able to break through to the next level. Out of frustration, he decided to take a break for a few weeks.
When he came back, he found himself breaking previous barriers with ease.
The lesson he shared in the book was one on the power of re-entry – “When you most feel you don’t need/can’t take a break is often when you most need one.”
Despite reading this book nearly a decade ago, this story is one that has stuck. Over the years, I’ve made an effort to be deliberate about breaks and re-entry. While these efforts have taken different flavors, the flavor I’m thinking about today is the weekend break.
Thanks to this story, I’ve experimented with various kinds of weekend breaks over the years. I have tried 24-36 hour technology black outs, no email Saturdays, and other such flavors. The current version that I’m liking a lot is the 48 hour break from work email. This means no looking at work email between Friday evening and Sunday evening.
I’ve implemented this over the past 18 months and have found that it gives me the space to re-evaluate how I’m approaching my work week while gaining much needed perspective on the challenging puzzle-of-the-moment. Most importantly, it provides the downtime to wholeheartedly connect with people that matter.
And, as I re-learn every week, re-entry is a powerful thing.
“Gully Boy” is a Hindi movie we watched twice in the last couple of months. It is available on Amazon Prime Video (with subtitles) and is a coming-of-age movie of a rapper from the slums of Mumbai. Hindi rap/hip hop is still a nascent music genre in India and the story is based on the true story of two Indian street rappers – Divine and Naezy.
There are many things I love about the movie – interesting characters, good music, and a nice story among them. Most of all, though, it speaks of the challenges of making your way up the privilege ladder when you are born in the slums.
Murad, the protagonist, needs several strokes of luck to make the leap – narrowly escaping going to prison for example – and also relies on the support of some incredible friends along his journey.
One of the most fascinating things about writing about privilege over the years is that nearly every one of the posts on the topic results in a response from someone arguing that I greatly under weight the importance of hard work. My thought experiment in response tends to be – how hard do you think folks in the slums of Mumbai work? I grew up witnessing abundant hard work in poor communities around me. What was absent was the platform that made all the hard work count.
Kids growing up in the slums worked hard to earn a few rupees to support their families every day while kids like me had the privilege to go to school and make something of our lives.
That is not to say a kid in the slums has no chance of breaking out. The odds of that happening are just infinitesimal compared to a kid with supportive parents going to an elite school.
Privilege is powerful. “Gully Boy” is a great reminder of that.
We’re about 2 weeks away from celebrating the 11th year anniversary of this blog. As I think about the evolution of this blog and the time I spend blogging/writing, I realize that this blog has evolved to a product of two co-authors – my wife and I.
While she has certainly influenced my thinking and posts over the years, her partnership and support since we’ve had kids is really what makes this possible. Time in the day flies quickly with two young kids. So, it takes extra effort to carve out pockets of time to share my notes for the day. And, that wouldn’t be possible without her unflinching support.
I don’t often express my gratitude to her here. But, as the person who does 90% of the work and gets 10% of the credit, I thought I’d do so today.
Much of our ability to effect change in the long run lies in our ability to consistently do two sets of things – i) acknowledging and then accepting our missteps and ii) making peace with being temporarily (sometimes permanently) misunderstood.
The first ensures we have the mental and emotional agility to adapt to the dynamics of the situation we’re dealing with.
The second, on the other hand, helps us to not lose heart.
Someone I know recently spoke about the significance of a watch he’d received from his parents. Aside from the fact it was gifted to him by his parents, he spoke about what it had taught him about time.
In addition to reminding him to respect time and be punctual, he spoke of the idea that “this too shall pass.”
It is a simple and powerful reminder of the transient nature of things. We go through ups and downs that all seem permanent in the moment.
But, it is all just a matter of time of perspective.
This too shall pass.
Observation: the more we observe someone go out of their way to explain they don’t care about something, the higher the level of certainty that they actually do care about it.
Applies to when we hear ourselves do the same as well.
As I was walking lost in thought to another building recently, I failed to notice someone walking a few yards behind me. As he overtook me, he told me off for not holding the door open for him.
As I snapped out of my thoughts and processed what he said, I realized I thought his comment sounded harsh. I had phrases like “how entitled” flying around my subconscious.
So, I continued to follow him with the intention of saying something about it.
Until I didn’t.
I’ve been paying more attention to my habitual attempt to have the last word of late. It comes from my reflex to fight fire with fire.
As I pay more attention to this, I’m learning to let go and separate stimulus from response from time to time. It doesn’t always happen. But, it is at least beginning to happen more frequently than it used to.
It turns out that I do just fine without having the last word – in case you were wondering. :-)
If anything, it actually results in less time spent dwelling on such situations. And, it is resulting in an improvement in my ability to look at feedback as input (more on that another day).
It was just another reminder of “when you want to fight fire with fire, remember that the fire department uses water.”
Here’s to more of them.
Early childhood is a tough process for kids. They’re exposed to plenty of new stimuli every day and have to figure out how to process all of it. And, every time they get tired of exploring the many possibilities in front of them or fall sick (happens as soon as they meet other kids :-)), they seek comfort. For a large proportion of infants and toddlers, that source of comfort turns out to be mom.
I was introduced to this wonderful 3 min 15 sec SNL sketch called “The day you were born” this weekend. Amy Schumer plays the mom receiving a mother’s day gift – breakfast in bed – from her son. And, the video wonderfully contrasts what she says about the day he was born and his early years with the actual chaotic and painful experience.
It ends with the line – “Thank you for pretending it was easy.”
As I see this movie play out day in and day out, it resonated deeply.
Thank you to all the engaged moms and dads who, well… engage. It matters.
And, while I know it is going to be a busy week, I hope you find some time to call your parents.
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 –
—
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 –
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
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.
A Learning a Day 