Marty Cagan's "Product is Hard" event

product management May 14, 2019

Marty Cagan: Product is Hard

A huge thanks to Josie-Dee Seagren for taking crazy good notes and co-authoring this post with me.

On May 13, 2019, I attended a talk by Marty Cagan called Product is Hard. I have read his blog posts and his book ‘INSPIRED’, and it was such a treat listening to this talk and meeting him in person.

Here were Josie-Dee’s and my notes and main takeaways from the talk.

Why product is hard

Frustration with lean & agile
Validating ideas vs. discovering solutions
Planning vs. prototyping
Not thinking broadly enough about risks
Not thinking about ethical risks
Playing defense vs. offense
Confusing optimization with discovery
Qualitative vs. quantitative
Not considering alternative solutions or approaches
Product manager competence
Coaching product managers
Truly empowered teams

1. Frustration with lean & agile

Lean and Agile are not wrong. They have very simple core principles, which are almost indisputably good.

So the problem is not with principles. The problem is with the application of these principles. Most teams are being given a roadmap and told to build features. That is not the right application of agile. Instead, leadership needs to trust teams and give them business problems to solve and iterate.

Also teams must ship at least once every 2 weeks. This is where the real benefits of agile come in. Without shipping this frequently, teams cannot learn fast enough, in order to build things customers actually want.

One agile framework, SAFe, is antithesis of agile. It doesn’t work in practice, and it’s not what he’s talking about when he says agile. Instead fail, learn, and ship fast while minimizing waste and maximizing value. Don’t spend 6 months building an MVP that doesn’t work. Spend the minimum amount of effort required to return the maximum amount of data to inform the next iteration.

Another huge problem on this topic is that companies mix up discovery and delivery. These are two separate and often parallel tracks done by the same team. Discovery is about finding a solution that will work, and delivery is about...well, delivering the solution :).

The discovered solution must be valuable, usable, feasible, and viable. Feasible in the sense that the team has the right talent and technology to build it, and viable for both customers and for the business - e.g., Airbnb's solution is sometimes not viable for their business when cities block it. And of course the delivered solution has to be reliable, scalable, performant, maintainable, international, and accessible.

Problems start when teams try to do both of these with the same tool, i.e. engineers. So they end up building a 4 month long MVP, which is neither a good discovery tool nor a good delivery tool – it’s a compromise that doesn’t deliver maximum value for minimum about of work. MVPs shouldn’t be scalable, they should be prototypes that are testable.Discovery and delivery can absolutely happen in parallel, which Marty refers to as dual track agile. , or "build the right product, and build the product right". Airbnb calls it “build things that don’t scale” (discovery)" build things that do scale" (delivery).

How do you know when it’s time to move from MVP to start building a scalable product? The answer is judgement is about risk. Are the tech lead, PM, and UX designer bought in and in alignment that any identified risks are under control, and that the riskiest assumptions have been tested enough? Although of you try and test every single thing, it will take way too long and cost too much money. So it’s always about judgement.

2. Validating ideas vs. discovering solutions

Product teams should be able to figure out quickly if ideas can pan out... but most ideas won’t work. At Google, allegedly only 10-20% of ideas actually pan out. Product teams should be able to push back, but they shouldn’t become a gatekeeper or someone who only has a reputation of saying no. Instead, product managers should come up with solutions. They should try something, iterate, and find something that works. In this way, the company and team will respect you as a problem solver.

The problems that = PMs are tackling are getting harder to solve. A PM must learn quicker, ship faster, and become a better problem solver.

3. Planning vs. prototyping

Teams – and product managers – take too long prioritizing. That is because it’s easy and comfortable. Instead of planning and prioritizing, spend more time prototyping and testing. Try out a 100 different ideas, and you might end up building only 20 really good ones.

Use the Opportunity Assessment () or the Opportunity Tree by Teresa Torres to do a super quick assessment. Then get prototyping!

4. Not thinking broadly enough about risks

Teams love to test usability and feasibility. These are familiar to most teams and easier to test and measure. But what about the more important measures of success, viability and value? Focus more energy on testing these.

Why don't PMs test these enough? Often because their mindset is that this is responsibility of the CEO/executive/stakeholder to keep in mind. Just because someone asks for a feature doesn’t mean they’ve thought through all of the risks or details.

5. Not thinking about ethical risks

Legal and ethical risks are part of viability. And very often PMs are the first ones who get wind of issues or discover unintended, risky consequences. So prioritize them and escalate!

6. Playing defense vs. offense / 7. Confusing Optimization with Discovery

Lots of PMs are PMs in name only, when actually they do the job of a product owner. How can you tell the difference? Discovery is the day job of product managers.

If you are not spending time every day doing discovery and seeking to understand and anticipate your users’ needs and behaviors, then you are not acting as a real product manager.

The hard thing about product is that it has to be SO much better than the alternative that people will switch to you. 10X better, in fact!

Don't prematurely start optimizing (which is safe and focuses on minor tweaks for incremental improvement) vs. spending time on discovery (which is about rapid innovation and creative, bold ways of solving problems). This situation often occurs when startup founders leave. Founders know what is important to the business vs. just incidental to product success. It is the job of a PM to get inside your leadership’s head and get to know the company’s / product’s secret sauce.

As PMs, our job is to first create value and then capture some of that value. So don’t focus on optimization which is largely focused on capturing value too early.

8. Qualitative vs. Quantitative research

Data always beats opinions. But there HAS to be a balance with both qualitative and quantitative research.

Marty gave an example of Apple and Google. Supposedly Apple and Google are two ends of the spectrum; Apple is great at qualitative and Google is great at quantitative. But if you dig under the covers, they both use both kinds of research. Check out the Resources section at the end of the article for a look into Apple’s product discovery process.

9. Not considering alternative solutions or approaches

OKRs and problems (with intended business value / outcomes) should be used instead of roadmaps. A lot of PMs beat one idea or feature to death to achieve the intended business goal. Instead, they should try using Opportunity Tree mentioned above, which allows a PM to consider many different options, while also considering the risks.

For this to happen, the team must move from a command and control roadmap (driven from the top down) to autonomous and empowered problem solving teams. But that can only happen when you have strong leadership buy in OR a compelling reason. Marty saw this pivot happen at CarMax after their sister company (CircuitCity) went bankrupt due to Amazon’s competition.

10. Product Management competence

Marty admitted that the average capability of product managers has dropped over the last decade. Most PMs either think their job is a Product Owner, .or they don’t know what their responsibilities are.

He believes the blame lies on their managers, which he described as the weak link in product teams. To be a true high-achieving PM, build the following skill sets:

As a product manager, you must spend time with customers every single week, in order to continue building and refreshing your knowledge of the product’s customer / user You must be a strong advocate for your product, and you should take ownership of knowing the ins and outs of industry trends, go-to-market and , sales approach, and the financial and compliance aspects of the product / business. You should learn most of this during the first 2-3 months onboarding in a new role. A lot of people get out of their responsibility for knowing these by escalating to the CEO or calling a stakeholder meeting to make decisions (design by committee). If you do that frequently, you are not doing your job. Get your team together and facilitate good decisions. As Jeff Bezos said, think and operate like an owner, not an employee. Last but not least, Marty reiterated that PMs should give engineers problems to solve and customer context. Don't give them feature to build. They will likely come up with far better solutions than you as a PM ever could.

11. Coaching product managers

Coaching, teaching, mentoring other PMs should be the #1 responsibility of a manager of PMs. But very often they treat this as the third most important responsibility. By helping others grow, you are empowering them to tackle the hard problems of product Marty spoke about – and this will make your job as a manager easier in the long-run.

12. Building truly empowered teams

Back to the core principles of agile teams – product teams must be empowered to take ownership over making decisions about their product. Marty says that truly empowered and accountable teams:

Have competent people with character
Have a diverse and complementary range of skills
Trust each other
Are given problems to solve, not features to build
Are accountable for solving customer and business problems (with associated outcomes); often in terms of OKRs

How to improve your PM skills

Marty offered the packed room of PMs some final words of wisdom about how to continuously grow your competence and confidence, whether you’re just starting out or a seasoned PM. Go work for an amazing manager and work for them for 1-2 years. This is the best way to learn. Set expectations and make sure they know you want to learn; that they are dedicated to making you become awesome. Other tips for PMs:

Start your day with 30 minutes of data analysis; this could include customer web traffic (i.e. Google Analytics), sales pipeline data (i.e. SalesForce), or digging into your data warehouse. Get your hands dirty; don’t wait for someone else to provide you that data
Solve hard problems that your customers love, but that also work for the business.
Spend your days in discovery. This is the real day job of a PM.
One of the hardest things about product is that you have to make your solution so much better than alternative that people switch. Ben Horowitz says it has to be 10x better! You get this by iteration, not prioritization.
The single best source of innovation is engineers, and the way to enable them to innovate is not to hand them features but to give them customer problems and articulate the user and business context. Don’t give them product requirement documents (PRD) or a list of user stories.
On the topic of tech skills: Companies sometimes look for an undergrad degree in computer science, but you don’t have to be a programmer to be a good PM (or have an MBA, for that matter). However you should at least be somewhat literate in programming... this is very easily overcome with just 1 class. So identify your gaps and figure out how to fill them. Here is an article Marty wrote about PM skill gaps and how to overcome them.
Most companies are judging two things when they interview you - your intelligence and your work ethic. Your work ethic is all about your displaying an owner's mindset.
If you liked the blog post, you will love my free course “How to be an outstanding Product Leader without working insane hours.” Go ahead, enroll now!

Resources

Hard thing about hard things - Ben Horowitz (For CEOs of startups, product managers).
Apple discovery process book (iPhone): Creative Selection
Opportunity Solution tree by Teresa Torres
Stratechery by Ben Thompson (blog) + Exponent (podcast)
Marty’s book: INSPIRED