Product Management Explained

Product management can seem like a bit of everything, and not much of anything, but the function of the product manager is to represent the customer throughout the product lifecycle, which spans research, design, development, marketing/sales, and customer support.

As a product manager, you discover who the customer is, what problem the customer has, and how to solve it - and then represent the customer relentlessly. You work with engineers and UX designers to build a product that solves the customer's problem. You also work with marketing, sales, and customer support, to explain the product to the customer, and, more importantly, to get actionable feedback from the customer.

Great product managers are excellent UX designers, engineers, and have a deep understanding of the product domain, but most don’t have all three skill sets. Make sure you have at least one and then come up to speed on the others before getting into product management.

Above all else, remember that three pillars are needed to support a great product:

Utility: The product must do what the customer wants it to do.

Usability: The product must be designed in such a way that the customer understands how to use it.

Reliability: The product must be reliable enough that the customer trusts it.

The pillars above are essential, but also try to add a hook so that customers will keep coming back for more.

The remainder of this post describes how a product manager contributes to the product development lifecycle:

1. Find and plan the right opportunity
2. Design the solution
3. Build the solution
4. Promote the solution
5. Assess the solution

Finding the Product Opportunity

Start with Why

Simon Sinek gave a famous TED talk, and wrote a book, on the importance of starting with “why”. Sinek defined the “golden circle”, which has "why" at the centre, "how" in the middle layer, and "what" at the outside. Sinke’s point is that the product journey should begin by asking why a company exists. This question must be answered before thinking about the product.

Personas

After you’re clear on why your company exists you need to know who your customers are. Personas are fictional characters that help you understand the real people who’s problems will be solved by the product. Personas should include things like the persona’s name, an image, age, gender, job title, pain points, objectives, interests etc. Personas should include enough detail to understand the customer’s perspective, but not become an exercise in creative writing. Stick to the facts.

Sanity Checks

It’s important to perform sanity checks at regular intervals. The first sanity check should be conducted before even starting. A quick 5C analysis is might be helpful. This involves writing a short analysis of the company, customers, collaborators, competitors, and climate.

Find out What Customers Want

Companies most often fail because they don’t have enough customers. If you want to avoid not having customers you need to build products that your customers want, and are willing to pay for. But how do you find out what customers want? Let’s begin with three things not to do:

First, never use surveys. Surveys don’t work. Customers don’t have any idea what they want or need, and they lie constantly.

Second, never do group brainstorming sessions. All you’ll hear at brainstorming sessions are the same tired ideas from the blowhards, and you’ll irritate everyone else.

Third, everyone has an opinion on what customer’s want. Opinions are worthless. Only experiences count, and only hard data has value. Discard opinions and begin with experiences. Even then, everything's a hypothesis until it’s tested and measured with real customers.

Working Backwards

The AWS working backwards approach is an excellent way to form a hypothesis. The working backwards approach begins by writing a press release. The idea is that you begin in the future where the product has been released with great success and happy customers, and work backwards from there. The press release should include the following:

• A heading that clearly names the product and describes in no uncertain terms what the product is.
• A subheading identifies the customer and describes the product’s benefit.
• A stand-alone summary that describes the problem, benefit etc.
• A description of the problem that your product solves.
• A description of how your product solves the problem.
• An inspirational quote from a company spokesperson that describes how the product will help customers.
• A call to actions that explains how easy it is to get started.
• A testimonial from a customer.

Colleague Ideas

People in your company will have product ideas. Some will be good, but most will never see the light of day because the ideas are bad, or because of insufficient resources. Weed the ideas out by demanding that everyone (including you) writes up their ideas as a press release. Make sure that everyone understands that nothing will be considered unless it is in this form. Publish all incoming ideas so that everyone in the company can comment on them. Also include your critique and a decision on whether or not the idea will be built. People will accept a no if it’s explained. A justified no is much better than having your idea ignored.

Boss ideas are harder - you’ll need to apply your negotiation techniques here. As a product manager you’ll need to be a negotiator.

Fleshing Out

Candidate hypotheses need to be fleshed out with use cases. Use cases describe how each persona will use the product. Document and publish these with the press releases.

Before moving on, make sure that you’re watching your competitors closely and constantly. See what they’re doing. Don’t copy them, but don’t get caught out by burying your head in the sand. Customer research is another sanity check.

Sanity Checks

It’s easy to build a product that customers won’t pay for. Perform the following analyses to help avoid failure:

Gains and Pains. Understand how your product solves a pain or makes a gain for the customer. What is the customers pain? How does the product solve it? How can the customer gain? How does the product help him gain?

SWOT analysis. SWOT stands for strengths, weaknesses, opportunities, and threats. Documenting these is another good sanity check before building anything.

Wants vs Needs. Give customers what they want, not what they need. Do customers actually want your hypothetical product or do you just think they need it?

Talk to customers. Don’t ask customers if they like your product idea - they’ll lie. Instead, ask them about their problems and wants. Talk to as many customers as possible, but without using leading questions. Look for themes. Will your product be relevant? Don’t ask customers what they would do, ask them what they actually do. Don’t ask them how much they would pay for your product, instead ask how much they pay for their current solution. Also ask them about their current workflows to better understand their pain points.

As a final checklist answer each of these questions:

• Is the product consistent with why our company exists?
• Do we have the capability to build the product?
• Do we have reliable data that indicates that the product will be successful?
• How does the product solve the customer’s problem?
• Will the product be relevant 5 years from now?
• Are we almost certain that customers will pay for the product?
• Can we support and scale the product if it succeeds?

Product Requirement Document and the Roadmap

The Product Requirements Document (PRD) defines why you’re building the product, the scope (features/functionality) and what’s not in scope. The PRD should be updated constantly, and it should be communicated widely and regularly. It should be one of the main pages, if not the homepage, in your document management system. The PRD should cover the following topics, perhaps by linking or merging some of the documents discussed earlier:

• The product’s name
• Document change history
• A summary
• How the product solves a customer problem
• The metrics for success
• Messaging for marketing purposes
• Timelines for development and release
• Personas
• Use cases
• Features
• Draft UX designs
• Open questions and issues
• The minimum viable product

In addition to the PRD you should create a roadmap. A roadmap ensures that everyone is heading in the right direction. The roadmap needs to be communicated - repeatedly.

Designing the Product

Opinions are worthless - metrics have value. Arguments about user GUIs, for example, are as pointless as they are inevitable. All suggestions should be based on experience, and then measured for effectiveness if implemented.

Designing the solution is typically a task for the design team. You should provide guidance and feedback, but you need to trust your designers with the task of designing. This is important if you want to foster a good working relationship with the design team. The job of the product manager is to represent the customer, but don’t make the mistake of thinking that you actually know what the customer thinks or how he’ll react. Your tastes and preferences are not those of the customer. Product managers must use metrics and a methodical scientific approach, and not make arbitrary decisions.

Most product managers make the mistake of not including the engineering team in the design phase. Engineering shouldn’t guide the product design, but it’s important to know if you’re trying to build the impossible. Ask the engineering team for feedback from day one. There may be a happy compromise even if it’s not viable to build the product exactly as you envisioned.

Leave the design to the design team, especially if you’re not a UX designer by trade. However, if there’s one thing you need to know about UX design it’s that the design should not make the customer think. Everything should be where it normally is, and it should work the way such products normally work. Avoid forcing the customer to make decisions. If, for example, you’re building a SaaS product and you need tool tips or an intro tour then you need to improve your UX design so that you don’t need them. The best product is one that the customer already knows how to use, because it’s so obvious.

Pre-validation

It’s difficult to validate a product before it’s built, but there are methods that give an approximation.

The Google Five Day Sprint allows you to prototype a product within, as the name suggests, five days. This method allows you to create product ideas, build fake minimum viable products (MVPs) and test them very quickly. The key to success is coming up with creative ways to mock up a product, and observe how customers react before you build anything for real.

Another approach is the pre-order website. This involves creating a website for the product and marketing it as if the product actually exists. When customers go to pay for the product you come clean and say that it’s coming soon and that they can pre-order. The benefit of this approach is that you’re confirming that customers will actually hand over money in exchange for your product.

Yet another approach for pre-validation is to build a product that has a manual operation behind the scenes. This works well for apps and SaaS products. The product looks like the real deal, but you have a bunch of humans doing the work at the backend. This, again, reduces the amount of time you need to invest before you can validate the product.

Building the product

We’ve discussed fake MVPs, such as the five day design sprint, but a real MVP must actually deliver. An MVP is exactly as the name suggests, a minimum viable product, with the emphasis on both minimum and viable. It must be minimal, but it must also be a quality product that has the three pillars of utility, usability, and reliability. The key to a successful MVP is to strip out every feature that isn’t absolutely necessary - and to fend off colleagues who want to increase the scope. You must be brutal in your exclusion of anything more than the minimum features, but never sacrifice utility, usability and reliability.

Building the solution is typically the responsibility of the engineering team, but the product manager must stay involved. Ideally the product manager will understand engineering. Assuming that we’re talking about a software product, you should understand the cost of technical debt, how devops works, and how peer review works. If you don’t know how to code, the best advice is to never assume what’s easy and hard. Ask engineering before making product decisions based on what you think you know, because you could be, and probably are, wrong. This applies even if you began your career as a software engineer. Technology changes fast and you miss a lot of detail if you don’t have your head in the code.

Promoting the product

As a product manager you need to work with each of marketing, sales, and customer success/support. From a self-serving perspective you’ll gain valuable customer feedback from attending sales meetings and participating from time to time as a customer support or customer success representative.

You should know a bit about digital marketing. A few key terms are listed below:

• Impression: This means your ad was shown
• Pay per impression (PPI): You pay for the ad whenever it’s shown.
• Pay per click (PPC): You pay for the ad when someone clicks on it
• Pay per action (PPA): You pay when the user performs an action, such as downloading your app.
• Click-through rate (CTR): The proportion of people who click on your ad.
• Cost per impression (CPI): The cost to have your ad shown
• Cost per click (CPC): The cost of a click in PPC advertising
• Customer lifetime value (CLV/LTV): The revenue you expect to receive from a single customer during the product’s lifetime.
• Cost of acquisition: The amount of money you need to spend to acquire one customer.

Assessing the Product

You need good telemetry to make decisions. You should, for example, ensure that you have metrics on, and pay attention to, customer behaviour, product reliability, product performance, and profitability. Dave McClure’s pirate (AARRR) metrics are handy to remember (Acquisition, Activation, Retention, Referral, and Revenue). It’s important to separate vanity metrics from actionable metrics. It’s no good having high website traffic if nobody is buying your product.

There are tools for tracking customer behaviour (e.g. Segment). It’s important, however, to do your own data science so that you can find insights unique to your product. Avoid third party tools that don’t give you the data. You should learn how to use tools such as Python, Numpy, Scikit-learn, and Jupyter - or similar.

Be quantitative not qualitative. Your intuitions are wrong. Like a fighter-pilot you need to pay attention to your instruments if you want to avoid hitting the ground. If you think your intuitions are better than your instruments your product is as dead as the pilot who only looks out the window.

Metrics are critical but they can also be wrong. Coding errors often skew your analytics, and sometimes your analytics will be designed incorrectly. Be careful. Data science is messy and hard. Statistics is particularly counter-intuitive. Have you ever heard of the Monty Hall problem or the Martingale system?

Be careful with metrics like the Net Promoter Score (NPS), which is usually derived from survey questions such as “How likely are you to recommend my product?”. The NPS usually tells you how customers respond your question, rather than how likely they are to recommend your product. If you want to know how likely customers are to recommend your product you need to measure how often they recommend it. Track customer behaviour - not customer surveys.

All software product changes should be A/B tested. This means adding a feature switch so that only a portion of your customers experience the change. If the change reduces whatever it was that you were trying to increase (e.g. profitability) then the change was a failure. The effect of many software changes aren’t measurable or have no effect. This is common, but also not good. You’ve wasted time on something that had no effect. Even if the change is measurably an optimisation you need to be careful not to optimise for local maxima. You must always step back and look at the big picture.

You should also conduct usability tests. These involve testing your product on customers to see if they understand what it is and how to use it. It's critical to never help your participants in any way. Begin by asking them to describe what they see and how they think the product works before allowing them to do anything. Don’t tell them if they’re right or wrong, just let them find out for themselves by trying it. If a participant gets stuck you must not guide them. Wait to see if they can figure it out on their own. Only after allowing many minutes of struggle and failure should you assist - and only then if it’s necessary to move on to other parts of the product. Similarly, don’t answer questions. Participants will ask if they’re doing it right. Tell them that you’ll answer their questions at the end, but never answer questions during the test. If you rigidly refrain from helping and answering questions you’ll learn what’s wrong with your product. If not, you’ll learn nothing.

Conclusion

You need to be a jack of all trades to be a good product manager. You need to understand the product domain, you need to understand software engineering, you need to understand visual and UX design, and you need to understand marketing. Above all, you need to be curious and analytical - and never arrogant.