Lighting up your Product Management journey
Building killer products is like building fires. At different phases, the PM must choose the spot, prepare the hearth, find the fuel, place the logs, light up the kindle, fan the flames, and clear the smoke.
There are phases to building great products, and I’ll use the analogy of building a fire to lay out the phases. There are some strategic ways to think about each of these phases and some tactical things you can do to succeed, I’ll try to lay those out. Importantly, I’ll try to give examples of how enterprise products exhibit these phases because I’ve worked on enterprise stacks over the past two years.
In summary, the phases boil down to the following steps.
Pick the problem you’re going to solve. Get buy-in that this problem is worth solving. Identify multiple options that might help solve the problem. Know what primitive pieces build-up to the ultimate solution. Get early wins for the customer. And Launch big. Add functionality as you learn more. Keep the content flowing. Reduce Tech Debt and Product Debt. Articulate a long term roadmap and vision for this product suite.
Here’s the breakdown:
Choose the spot:
Pick the problem you’re going to solve.
- Strategy: Choose problems that come up most often from your most important customers, which will tangibly help increase either the bottom line ($) or Customer Satisfaction (NPS). There are two ways to think about this — what are customers directly asking for in terms of features, and what do they need but don’t yet know how to articulate.
- Tactic: Keep a running catalog of interview notes from your conversations with customers, Sales, and support. Tag those notes with each of the features people are requesting. Over time, patterns will emerge which will let you quantify the opportunity of different problems you might want to chase.
- Example: Bezos was an investor fascinated by the growth rate of the public internet. He was allegedly brainstorming ideas for a company that could leverage such a growing medium and after running through a thousand ideas, decided that an “Everything Store” was the one idea that could maximize the potential of the internet. Most consumers couldn’t find the book they were looking for in a small bookstore or library. Amazon started with Books because books came in standard sizes, book stores could have infinite catalogues, and shipping books was simple. It is now, really an everything store.
Prepare the hearth:
Get buy-in that this problem is worth solving.
Strategy: In every company, products get funded and de-funded based on various factors. Some factors are out of your control, but educating the heads of the business about the problem and articulating the positive results possible from solving it will help people understand why it is worth funding your idea. This includes giving you the design and development resources as well as placing the idea in the annual/quarterly business priorities doc the people refer to when they look for guidance. Remember to find and align with anyone else who is chasing a similar problem so you can share resources.
Tactic: Write up your thoughts on why this is a problem worth chasing. Run a survey with Customers, Sales, Support, or analyze usage data to identify main gaps and articulate how much revenue is being lost or users are churned due to a problem or how many people ask for the same problem to be solved in different ways. Point to how success will be measured. Make sure you present this document to as many higher-ups to get buy-in before jumping in too deep and starting to solve it all.
Example: Create a shared vision. Drew Houston posted a vision about a storage solution that did not require users to carry around a CD or USB drive to keep track of their files on Reddit. Suddenly Drew had 75k users sign up for early access within days. This was how Dropbox became a thing. See his Y combinator application here.
Find the fuel and the kindle:
Identify multiple options that might help solve the problem.
Strategy: Your duty is to find the most efficient ways to problem solve. Sometimes it means writing code, but sometimes it doesn’t. It is surprising how much some changes in Design, or Copy, or Documentation can accomplish. Sometimes you need to just create a tutorial and publish it online to solve a problem.
Tactic: Get a menu of options together. Organize your technical spec into user problems. User stories. Functional requirements of a solution in phases and priorities. Make Phase 1 sufficient to solve the core problem Priority 1 — essential functionality in phase 1
Example: Google a restaurant’s name and you’ll notice that they’ll surface details about the restaurant on the right from their own database, but they’ll also surface the yelp result as search links and a Maps link. Solving “local restaurant discovery” was a problem worth solving to Google and they approached it with each of these solutions. Currently, Google doesn’t offer restaurant table reservations directly, but their partnership with Open Table does that while they build/buy the capability.
Place the logs appropriately:
Know what primitive pieces build-up to the ultimate solution.
Strategy: Building solutions right means putting things in the right sequence. Start putting infrastructure in place. Show progress. Build on.
Tactics: Identify the core capability that lets you scale the solution. Then identify the features that should be built on top of the primitives to make features usable across use-cases.
Example: Within seven years after the primitives were launched, Google was able to map 100 countries (across massive places like India, Australia, Europe, and the US) and launch 3D views for consumers. Google Street View started with a simple idea — images could be stitched together and overlaid on a map to offer a “3D view” of a place. After that, the company instrumented vehicles likes cars (for the US), tuk-tuks, and even trikes (for India and Italy) with 3D cameras and got contractors to drive them across the world.
Light the kindle:
Get early wins for the customer. And Launch big.
Strategy: Show progress early. Consistently move the metrics you’re seeking to move and your team will earn trust and grow in resources. Build against your biggest unknowns to derisk the product. This frees you up to build the nice-to-have features with confidence.
Tactics: Deploy items that can be accomplished via docs or tutorials early. Launch early experiments and get validation. Show that a feature, however incomplete, can change product outcomes.
Example: Facebook launched the timeline for a small subset of users. The impact on engagement was so powerful that Facebook forced all its users to adopt this new style of facebook profiles, initially allowing people to opt-in to the layout and then mandating the roll-out. The PM would have tracked how engagement metrics differed between users after running an A-B test and Zuckerberg probably took the call to roll it out to 100% of users within months.
Fan the flames:
Push changes and marketing levers to ensure shipped products are known about.
Strategy: Products and market conditions evolve but the more you can get the word out, the better for your customers.
Tactics: Send Launch announcements across all the media available to you — Blogs, emails, UI changes, deal-desk, and intructional assets like courses and videos online. Answer questions on Stack overflow. Give talks at industry events.
Example: Airbnb evolved its offerings from just housing to include experiences. However, to get people to try an “experience”, they had to evolve the entire home-page of Airbnb and all the search results to be dominated with “Experience” options. All the interviews Airbnb execs gave were about how this new offering was going to change everything about the travel experience. It seems to be working as suggested by Airbnb’s valuation and stickiness.
Clear the smoke:
Reduce tech debt and product debt.
Strategy: Code becomes fragile at scale so add a bunch of regression testing requirements into your spec. Still, with all the edge cases you discover over time, you’ll have to get into a maintenance phase after you’ve launched so that you can build for the next parts of your roadmap. The goal is that the Engg team should be able to move on to building other things after the initial post-launch maintenance phase.
Tactics: Keep a running backlog of bugs in your ticketing system. The common practice is to chip away at bugs all the time but I’ve found that Sprints dedicated to fixing bugs are also good at getting the team mobilized and making notable progress. Most importantly, keep asking about the quality of test coverage in your product so that you are most prepared for disaster scenarios.
Example: Remember the early days of Twitter? The little blue bird would give way to the fail whale whenever Twitter was down. Over time, as Twitter scaled its infrastructure, it could handle large enough traffic to grow to the scale of trolling it now supports.
Light the way forward:
Articulate a long term roadmap and vision for the product suite.
Strategy: PMs should be the expert in the problem they’re solving. But PMs should also articulate a clear enough vision that they can hand-off execution to engineers and juniors so they can focus on the business strategy more closely.
Tactics: Layout a long-term roadmap. Start with an “ideal experience” that you’re striving for. Then chart out a path to what your product suite could look like years beyond the current moment.
Example: Bezos is rumored to have read a book called Elements and thought up the concept of AWS. He broke down web infrastructure into storage (S3) and compute (EC2) facilities and had the core idea — that the offering had to scale infinitely to be valuable to any and all customers. Once this was vetted Bezos laid out the vision that all applications could be built on an “Amazon Cloud” including any type of machine learning use-case, or anything someone could imagine, even quantum computing. This vision is now being executed by Andy Jassy now with incredible results.
There are so many examples, big and small that come to mind for each of these phases, but I hope the diverse ones I’ve highlighted convinced you to think about your ideas and break them down into the phases mentioned above.
Go light up your plans. And ship.
—
Please hit the ❤ a few times if you found this article useful so more people can find it.
