Product is Hard by Marty Cagan
These are my notes from a talk from Marty Cagan titled "Product is Hard." It's about product discovery & delivery.
Roadmaps do 2 things:
- They let the rest of the business (marketing, sales) know what's coming and when.
- They help ensure we're working on the most important things.
If you're going to do roadmaps, make them outcome-based. For each item on the roadmap, figure out what the business result is that would get better if we do this thing.
For example, the feature could be integrating a payment system (like PayPal). The outcome we're looking for is to increase conversion rate. So make the objective to increase conversion rate and put "integrate PayPal" on there as an option. The KPI is conversion rate. The target is increase up to 6%. As soon as it goes live, we start reporting on that business result.
Requirements vs Constraints
- designers must solve with constraints in mind
- PMs must do the work to understand the underlying constraints
- Too many companies let this get way out of control.
- If we can't respond to the market and take care of our customers.
- CTO or VPEng need to be responsible for taking care of tech debt. PMs don't get to say whether or not we do this.
- They force the cultural issues to the table.
- Rs are business results.
- OKRs are predicated on having a high level of competence of the team/org. you need to want to truly empower the team.
- Dual track: objectives -> discovery & delivery.
- Build the right product vs build the product right.
- Design sprints vs delivery sprints.
- Continuous discovery vs continuous delivery.
Solve business problems from an OKR (PM, tech lead, designer) and measure by outcome/results.
Engineers - should do 90% building. They should spend some time every day (even 15 minutes/day) getting shared learnings from product. Don't shelter the engineers; show them the customer in pain; it's motivating.
Discovery & Delivery
- Tackle risks up front.
- Define collaboratively.
- Focus on outcome not output.
- Value risk: would people buy it.
- Usability risk: can they figure out how to use it.
- Feasibility risk: can we actually build it.
- Viability risk: will it work for the stakeholders in the business.
- Usability - could they use it, usability testing.
- Value - would they use it/pay for it.
- Feasibility -then, bring in engineers to scope/dig into feasibility, break it down.
- Viability: PM looks at the feature and figures out who she needs to talk with (approval, compliance, stakeholders); if we get the ok, then it goes on the backlog.
- Feature is now on the backlog for a development team to work on.
- Now we are engineering & thinking about scalability, reliability, performance, maintainability.
Thoughts on Culture
- PMs job is to ensure their engineers are missionaries.
- Introduce the engineers to customers.
- Share full business context with the team; it helps and motivates them.
- AWS developers have constant access to the customers.