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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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:
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:
Join our community as we work together on one new Product Management practice a week!