What does it even mean to 'transform' your product org?

Hey folks,  Marty Cagan is a legend, so unsurprisingly his talk smashed all popularity records at this year's Product Drive (4,739 of you signed up for this talk alone 🤯) - but what the heck does he even mean by "Product Operating Model"? Do product orgs still need to get "transformed"? Isn't everyone these days "outcome driven" and "agile"? Isn't Marty simply out of touch? 

No. Many product orgs hide behind the veil of 'fake agile' while in fact still making product decisions by committee. 

How do you decide which problems to solve? 

How do you solve these problems? 

How do you deploy and test those solutions?  Be honest. 

What is the "Product Operating Model" and why many product companies still haven't embraced it?

"Product Operating Model" emphasizes the importance of empowered product teams working collaboratively to deliver products that truly address customer needs. But how can product teams do that if they are still supposed to build features based on roadmaps arbitrarily created by execs? 

If a problem that the product team is trying to solve is put on a roadmap - they won't be empowered to find the best solution. Usually because people that put problems on the roadmap do not understand the enabling technology. That’s why innovation almost never happens in a roadmap model / feature model, but in a product model - because the engineers work with the enabling technology every day and we often come up with much more innovative, better solutions. That’s the premise of the empowered product team. 

And in Marty's words: “The value of the product is a measure of how good you do these things” 

So what does it really mean to empower a product team?

It means you give the team a problem to solve, and they come up with the best solution to that problem.  The team needs to be allowed to solve the problem and be accountable for the outcome, by:  

1. Changing how you decide which problems to solve. Stop senior leaders from deciding how much engineering capacity is going to be allocated to each business unit. The language they use is “we need this feature” This changes in the Product Model. The allocation should be done based on the importance of the problems that need to be solved. This is hard because it requires a political change and a change in corporate dynamics.   
2. Changing how you solve problems - stop just executing the roadmap, and do proper product discovery. Don’t squish technology and solutions, and just deliver and hope you got it right. Product discovery is mostly solution discovery. You first need to understand the problem. Identifying the problem worth chasing (this is product strategy that comes from the product leaders, not just from researchers!)   
3.  Not everything you build needs to be a problem to solve  - some things are just ‘keeping the lights on’ - you just put it on the backlog, and build the damn thing - just knock it out, don’t sweat it - or you won’t have time for real problems.   
4. Beware of the ‘all about the user’ fallacy - it has to be viable. Not necessarily immediately profitable - but viable in the sense that it is bringing business outcomes.   
5. Product discovery =/= research =/= R&D. The real, true research requires a lot of engineering resources to create a new technology, rather than how to solve an existing problem using existing solutions.   
6. Changing how you build -  you need to have small, frequent, reliable release vehicles - releasing once per month or quarterly is not enough to keep your users happy! The releases need to happen no less frequently than every two weeks, and ideally each change should have its own atomic release. 

Watch the replay of Marty's presentation to learn more about how to act on your product data!  

And now...what's new in Userpilot? 🤔 🎁 🎉  

The summer may be over, but we haven't fallen into winter sleep! Here's a short summary of our September product updates: 

• Autocapture: Userpiliot now automatically captures all raw events (clicks, text input, form submissions) and lets you label them using a visual labeler. 
• Funnel analysis improvements: You're not able to set funnel conversion windows by minutes, hours, days, or weeks for more flexible insights.

• Salesforce Knowledge Integration: You can now integrate Salesforce Knowledge to let users access articles within the Resource Center.
• Accessibility in the Resource Center: We added ARIA labels and roles to make the Resource Center accessible for visually impaired users.
• User Feedback - Survey Updates: You can now launch center-positioned surveys, time-based recurrence, and export specific survey responses. 

+ we're cooking some new releases, including onboarding for native mobile apps, session replay, and Intercom knowledge base integration! 🤩

Sounds good? Great?

Book a demo to learn more about the product & upcoming releases.  And see you all next week!