A Primer to Product Management

I was recently asked to speak at the Boulder UI/UX Meetup, and had such an awesome time preparing for it that I wanted to write about the experience. Quick disclaimer: there are so many topics in the talk that I wanted to dive a bit deeper into but was constrained on time.

Product Management has been around for a while, but the practice really changed for the software industry after the Agile Manifesto redefined how teams should work in 2001. Since its shift into software, the role of Product Manager varies from company to company so it was fun to explore the gifts of the internet and see whether or not certain Product Management practices differed by industry. By and large, most articles aligned with my expectations, but I felt that Josh Elman’s statement about Product Management was the most succinct and applicable to my experience.

Therefore, I framed my discussion around his statement:

Help your team (and company) ship the right product to your user.

Helping Your Team

The first part of the statement, “help your team” covers the more tactical practices, such as grooming the backlog, building the roadmap, managing ops, and writing good stories. The general takeaways are:

• Write small stories: The size of the story should be the smallest possible while still delivering value to your end user. Smaller stories falls in line with Agile’s principle of people over process. Don’t spend all your time writing stories; the stories should instead be placeholders for conversation. Smaller stories also allow for shorter feedback loops so you know you have (or haven’t) added value for your user before you spend a bunch of time building something.
• PMs are not the “CEO of the Product”: I firmly believe that PMs should be facilitating discussions to bring the best ideas out of the team; they are not dictating direction. The roadmap is a team effort that is best articulated with a co-located, balanced team.
• Steward of Team Happiness: As a PM, one of your top priorities is making sure the team is happy. That could be achieved through a well groomed backlog (are all the assets that need to be attached to stories there?) or it could be making sure the team is not working weekends. This can take many forms, but you want to avoid this level of frustration from your team

Avoid (as much as possible) team frustration

(and Company)

By adding “and company” as another component to helping your team, it highlights the strategic element of Product Management. It is just as important for the PM to understand the team’s goals as the company’s goals. Therefore, understanding the domain, identifying trends, and taking advantage of the right opportunities all fall under the PM’s purview.

Ship

The second part of the statement, “ship,” covers the PM’s responsibility to ship the product. Although it’s fun to dream about all the cool features, at some point, you have to get the product out the door. There’s a great talk that Lauren Gilchrist gave about shipping imperfect products. She also has a great analogy of how we should all move away from this idea of being an expert, and move towards being a scientist. There are too many unknowns in the world, and the pace in which software disrupts industries means that you can’t know it all.

Therefore, the solution is shipping early and often in order to build the evidence towards what to build next. A false hypothesis is still valuable because it teaches you that your assumptions were wrong. Only the market could have taught you this, no matter what kind of expert you are.

The Right Product

“The right product” section covers the topic of defining MVP, testing, and measuring. I use the cupcake model to talk through how MVP needs to have both desirability and completeness. However, MVP is just the first step of finding the right product, and I know the term itself is quite loaded. For startups, it may be easier to define because your customer is more easily defined. But for enterprise products, there are usually a lot more stakeholders and their definitions of desirability and completeness can vary depending on their goals.

Therefore, working together with your team, create different experiments to test out your riskiest assumptions. The right test can save both time and money without having to build out a full product. The following are different types of tests, but keep in mind that they each have different applications at different steps in the validation process. For example, surveys and Net Promoter Scores are only useful if you have a very large sample size and the assumption is very quantitative.

1. Customer discovery interview
2. Data Mining
3. Surveys
4. Net Promoter Score
5. Concierge Testing
6. Wizard of Oz Testing
7. Product Analytics / Dashboard
8. Smoke Test
9. Published and validated Research
10. Solution Test

For how we address measuring results, I use Ash Maurya’s framework from his new book, Scaling Lean. I appreciate how he approaches the typical “pirate metrics” (Acquisition, Activation, Retention, Referral, and Revenue) in a nonlinear way. He deconstructs the term “traction” into a handful of key levers so you know what to measure and can ignore the non-actionable data.

Credits: Ash Maurya, Scaling Lean

To Your User

The final part of the statement, “to your user,” highlights how to define your user, and how do you get your users to care about your product.

When you’re in the earlier stages of a product, making sure you’re focused on one or two user personas is important. This can help to design the right user experience. However, as products evolve over time, it’s important that the business thinks about potential customers as well. As you conduct your user research, keep in mind that current customers probably won’t give you feedback that will make their current implementation obsolete, so you have to be alert and ask around the “why”.

For example, an instructor at Pragmatic Marketing once shared a story where he and his wife built their own house in the late 90s. They were both technologists, so they actually wired their entire house with CAT5 internet cables. At the time, Cisco was just starting to explore expanding from the commercial router market for residential use. When they did a user interview with him, he told them he wanted two things: Faster speed and more ports. He never would have told them (wait for it)… WIRELESS. Building wireless routers made it so that the potential customers became customers.

The other story I shared in this section was the story told by Bret Taylor and Google Maps. My two takeaways from the article were:

• Familiarity can be a fatal weakness
• Build a lens to allow users to see a new world rather than features to help them see an old world better

I thought these were particularly insightful since oftentimes as PMs, we want to use other products to compare and contrast to our own. It can be a way to affirm our decisions or think that we have a shortcut to our users. Instead, we have to be deliberate about each experience we create, and we need to think deeply about user needs. What solutions are we providing that others are not?

That concludes my talk, and huge thanks to all the wonderful folks that were cited in this post (and BJ Cooper for his mentorship and all-around awesomeness). I welcome your thoughts on how your definition of Product Management may differ!

Here is a more “sharable” version of the deck in case you are interested.