Personal IPOs and stock market tickers

Eugene Wei had a post on his excellent blog yesterday where he drew parallels between individuals building brands on social media and a company going public.

One way to understand the impact of these public social networks on humanity is to think of this as the era in which humans took their personal thoughts and lives public at scale. Billions of humans IPO’d, whether we were ready for it or not, explaining why the concept of a personal “brand” became such a pervasive metaphor.

In another era, most of us lived in social circles of limited scope. Family, school, coworkers, neighbors. We were, for the most part, private entities. Social media companies quickly hit on the ideal configuration for rapid network growth: take the interaction between any two people and make it public. Conversation and information-sharing became a democratic form of performance art.

One reason social networks quickly converged on this as the optimal strategy and configuration is that the majority of people on any social network merely lurk. By making the conversations of the more extroverted, productive nodes public, you sustain the interest of that silent majority of observers with what is effectively crowd-sourced (read: free) content. The concept of 1/9/90 is that a stable equilibrium can be achieved in a large network if the shouting class, the minority which entertains the much larger but silent majority, is given enough quantifiable doses of affirmation (likes) to keep the content spigot flowing. As these large public social networks grew, even many who were previously modest began taking the stage on social media to karaoke to the crowd. Live fast, die young, and leave a viral post.

Just as there are many advantages to being a public company, becoming a public figure carries all sorts of upside. Once your ideas and your self are traded publicly, anyone can invest and drive the value of those goods higher. If you’ve ever written a viral blog post or tweetstorm and gained thousands of followers, if you’ve had a YouTube video picked up by traditional media and found yourselves interviewed on the local news, you’ve felt that rush of being a soaring stock. Social networks not only provide public liquidity for anything you care to share on them, but they also continued to tweak their algorithms to accelerate the virality quotient of their feeds. In a previous generation, Warhol quipped the duration of sudden fame was 15 minutes, but social media has made that the time it takes to become famous.

The problem is that, like many private companies who find the scrutiny of public markets overly stringent, many of us were ill-equipped for “going public” with what were once private conversations and thought. It’s not just those who made enormous public gaffes and got “canceled.” Most people by now have experienced the random attack from a troll, the distributed judgment of the public at large, and have realized the cost of living our lives in public. Most celebrities learn this lesson very early on, most companies put their public-facing executives through PR training, but most humans never grew up under the watchful gaze of hundreds of millions of eyes of Sauron.

It is a powerful analogy and it made me wonder about Instagram’s recent decision to remove “like” counts. If an Instagram profile is the equivalent of a stock ticker, a “like” may have been the equivalent of the stock price.

And, as there’s only so much good that can come from constantly monitoring short term fluctuations on your stock price, removing “like” counts may turn out to be a master stroke.

Marketing dog food and happiness

What does marketing dog food have to do with building products, success and happiness? Everything, it turns out.

When Paul Iams launched Iams 999 – a high quality, high protein variety of dog food – he didn’t have a distribution system. So, he needed customers who were willing to go through a lot of trouble to get this shipped over.

It turns out there was just this right group – owners of show dogs. These folks loved what was great about Iams (better health + shiny coats) and didn’t mind, or even liked, what was bad about it (hard to get => competitive advantage).

We are all not different from Paul Iams. When we seek partners, customers, and managers, we strike gold when we find folks who love what’s good about us and don’t mind what’s bad about us.

As these relationships start with appreciation of our strengths, these managers, partners, users, and team members give us the most useful feedback, push us to become better, and also give us air cover and support when we inevitably screw up. We all need that appreciation, push, and support to ship our best work.

And, making the effort to find our segment makes all the difference in the world.

Magic and math

A simple way to understand how investors think about our business/product – they come for the magic and stay for the math.

The inspiring story is the magic that many of us associate with charismatic leaders. In times when everything is going up and to the right, there’s a lot of appetite for magic.

Eventually, however, no amount of magic can save a business or product from the math. So, our ability to deliver and capture value in a way that results in consistent y/y growth rates is the kind of math that creates its own magic in the long run.

From time to time, it is natural to wonder how much more successful our businesses/products might be with more magic and showmanship.

But, that’s short term thinking. The magic is the personality and the math is the character. And, while personality opens doors, character keeps those doors open.

So, if we had to invest in just one thing, let that one thing be making the math work.

This applies just as well to those who invest in our careers/lives.

PS: Unlike investors, our users/customers are just as likely to stay for the magic as they are for the math.

Discomfort and the obstacle

On most days in my attempts to do a half decent job as a Product Manager, I see two themes show up regularly in my reflections – i) Something new either got messed up or got real close to getting messed up and ii) I did something that upset somebody.

And, a realization that has accompanied these reflections over time is that there is no solve for this. (This was disappointing.. until it was liberating.)

Here’s why  – if we’re both stretching ourselves beyond our comfort zone and attempting to drive change, it is impossible to avoid making mistakes. The only questions worth focusing on then are – are we aware of them? And, are we following up with creative, constructive, and corrective responses?

As long as we’re doing that, that uncomfortable feeling in the stomach is the price we pay for our own learning, long term growth, and, hopefully, progress.

Of course, this isn’t limited to product management – it applies just as well to many jobs, to parenting, and to life.

The discomfort is a leading indicator of the obstacle. And, the obstacle is the way.

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 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 “” 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.