Prioritisation & Discovery vs Delivery with Welcome & Lenses PMs
•Download as PPTX, PDF•
1 like•206 views
From this presentation you will learn about Prioritisation & Discovery vs Delivery
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Prioritisation & Discovery vs Delivery with Welcome & Lenses PMs
Similar to Prioritisation & Discovery vs Delivery with Welcome & Lenses PMs (20)
More from Product School
More from Product School (20)
Recently uploaded
Recently uploaded (20)
Prioritisation & Discovery vs Delivery with Welcome & Lenses PMs
- 1. www.productschool.com Prioritisation & Discovery vs Delivery with Welcome & Lenses PMs
- 2. Join 40,000+ Product Managers on Free Resources Discover great job opportunities Job Portal prdct.school/PSJobPortalprdct.school/events-slack
- 3. CERTIFICATES Your Product Management Certificate Path Product Leadership Certificate™ Full Stack Product Management Certificate™ Product Management Certificate™ 20 HOURS40 HOURS40 HOURS
- 4. Corporate Training Level up your team’s Product Management skills
- 6. Discovery Delivery Explore Problem Area ⭧ Define Problem Statement ⭧ Explore Solutions ⭧ Deliver Solution ⭧ ⭧ ⭧ T H E F R A M E W O R K
- 7. Discovery: - Interviewing - Understanding - Mapping - Communicating - Prototyping - Getting buy-in - Selling - Negotiating - ... D I S C O V E R Y & D E L I V E R Y Delivery: - Aligning - Planning - Measuring - Selling - Negotiating - Prototyping - Testing - Celebrating - ...
- 8. A N E X A M P L E F R O M C O N T E N T F U L “We need Content Workflows”
- 9. Discovery Delivery Explore Problem Area ⭧ Define Problem Statement ⭧ Explore Solutions ⭧ Deliver Solution ⭧ ⭧ ⭧ 1. E X P L O R E
- 10. 1. E X P L O R E
- 11. 1. E X P L O R E
- 12. 1. E X P L O R E All competitors are doing the same. “Workflows?” “More like Collaboration” 1 2
- 13. Discovery Delivery Explore Problem Area ⭧ Define Problem Statement ⭧ Explore Solutions ⭧ Deliver Solution ⭧ ⭧ ⭧ 2. D E F I N E
- 14. 2. D E F I N E
- 15. 2. D E F I N E
- 16. 2. D E F I N E Jeff Patton’s: Opportunity Canvas Eric Ries’: Lean Canvas
- 17. 2. D E F I N E Fake Press Release User Story Map
- 18. 2. A G O O D P R O B L E M S T A T E M E N T ● Solution agnostic ● User focused ● Business-impactful ● Measurable ● Inspiring
- 19. Discovery Delivery Explore Problem Area ⭧ Define Problem Statement ⭧ Explore Solutions ⭧ Deliver Solution ⭧ ⭧ ⭧ 3 . P R O T O T Y P E
- 20. 3 . P R O T O T Y P E
- 21. Discovery Delivery Explore Problem Area ⭧ Define Problem Statement ⭧ Explore Solutions ⭧ Deliver Solution ⭧ ⭧ ⭧ 4 .D E L I V E R
- 22. W A T E R F A L L M U C H ?
- 23. W A T E R F A L L M U C H ?
- 24. Time (weeks) R E A L T I M E
- 25. Time (weeks) R E A L T I M E
- 26. R E A L T I M E
- 27. Time (weeks) W H A T A B O U T S C R U M ?
- 29. A B O U T C O M P E T I T I O N
- 30. A B O U T C O M P E T I T I O N Which one is the Macbook?
- 31. A B O U T C O M P E T I T I O N Not a Tesla
- 32. H O W ? Explore here
- 33. H O W ? Explore here
- 34. C H A N G I N G C O U R S E You start here Default future Inspiration: Cone of possibilities You want to land here
- 35. C H A N G I N G C O U R S E You start here You want to land here Effort Default future Inspiration: Cone of possibilities
- 36. D I F F E R E N T I A T E E A R L Y You start here You want to land here Effort Too late! Default future Inspiration: Cone of possibilities
- 38. I N N O V A T I O N If you don’t build the right product it doesn’t matter if you build it right.
- 39. Thank you!
- 40. Appendix
- 41. A P P E N D I X “A Product Manager’s job is to discover a product that is valuable, usable and feasible” - Marty Cagan, founder SVPG
- 42. R E A L T I M E https://svpg.com/product-vs-feature-teams/
- 43. A P P E N D I X https://www.designcouncil.org.uk/news-opinion/what-framework-innovation-design-councils-evolved-double-diamond
- 44. A P PWE N D I X https://getenjoyhq.com/
- 45. www.productschool.com Part-time Product Management Training Courses and Corporate Training
Editor's Notes
- If you’re interested to connect with other Product Managers, aspiring PMs, or those within tech, join our Slack community of over 40,000 professionals. It’s a great place to network and to find interesting content. We host a weekly AMA through our Slack channel on Tuesdays from 11:15am - 12pm PST. We have also recently launched the Job Portal where you can find the latest Product Management opportunities! As members of the Product School community, we'd like to provide you with these resources at your disposal.
- Product School’s Product Management Certificate Path comprises of 3 part-time courses for professionals with strong technical or business background who want to further explore Product Management at software-based companies. During Product Management Training you will first learn Product Management fundamentals to understand the software product lifecycle and what it takes to successfully transition into a product management role. You’ll then be trained to retrieve data, understand its value and make impactful decisions with SQL, data visualization and Tableau. Learn to understand your users to deliver exceptional UX/UI design and develop a robust digital marketing plan. During the Full Stack Product Management Training, you will deep dive into the technical knowledge to enhance your ability to work with agile teams. Finally, Product Leadership Training will elevate your product knowledge to become an effective Product Leader. You'll do an in-depth analysis on how to implement best PM practices on a strategic level to significantly impact your company’s portfolio and revenue. Learn the soft skills to manage product teams and manage stakeholders to deliver performing products.
- As well as individual courses we provide corporate training across the world! If you’d like to upskill your product team this is the best option for you. We have trained employees from multiple companies such as Deloitte, Salesforce, JP Morgan, Bank of America amongst many other companies across all industries.
- Here it is in its whole glory. It is just a framework to help you balance your discovery task and delivery tasks. It is a marriage of product process and design thinking and was introduced by my smart colleagues at Contentful into our process. It consists of 2 main phases: Discovery and Delivery with each breaking further down into a diverge and converge phase.
- So, let’s take it for a spin. There is no better way to show it by giving you an example of how we applied it at Contentful. “We need Content Workflows” This is not a user story or a jtbd, it’s something though that the entire organization has been collectively knowing that we were missing, for years. A lot of customers were asking for this, we were losing deals, getting hammered by the competition and that we finally decided to take action as the time had come based on our company’s strategy.
- So, with starting with this item we started exploring the problem area: What does Content Workflow mean in terms of user needs? What does the competition do? How much does this hurt us, business-wise? What are the current alternatives our customers are using What are our stakeholders saying?
- This took about 2 months, while the development team was busy wrapping up the previous project, me and my product designer talked to about 10 enterprise customers, did extensive competitive analysis of 10+ competitors, held a workshop with 20 people from our sales, customer success, support departments, solution architects, sales engineers and talked to stakeholders.
- At the end of this phase we had, without exaggeration, hundreds of post-its with customer insights, a wiki page with a competitive analysis and video recordings of customer interviews.
- Even though we waited for the next phase to come up to conclusions we could already see a couple of trends emerging from all these insights. Every major competitor was playing on a level field. They were all doing the traditional workflows thing with the different content states. Workflows were more of an RFP feature that was requested by the CMO. The actual content creators craved for an easier way to communicate with content experts to get some help, review or action on their content piece. This is already smelling like a good way to solve an important problem in a way that was different from the competition.
- Now it was time to turn that mess into a meaningful thing, a single focused problem to solve. And if your team is autonomous enough (like a “product team” compared to a “feature team”) then this is where your job would mostly end.
- In the end, we created this opportunity canvas which listed information such as: the problem statement, the metrics, the target personas, the marketing release strategy, the effort, the business value. We used this format because it was easy to share across the entire org and provide the gist and it was also a single artifact that we used in our weekly product kanban meeting where we shared updates with the company.
- This is what our product kanban looked like, btw, which really helped communicate what each team was doing each week to the rest of the organization by mapping their own projects in their canvases on the board.
- If you want, you can use your own template that works better in your organization.
- Or you can use a fake Press Release, like Amazon does, or a User Story Map which shows the problem in a journey format. It’s really up to you and you can get really creative, like make a video or a prototype that illustrates your problem. Remember, this is your domain and this is one of your most important deliverables.
- Whatever you do, make sure that your problem definition has these attributes.
- Then we switched to prototype mode. Exercises like design studios and other co-creation workshops help you to get as many angles to the solution as possible. We then went with invision click-through prototypes and kept a feedback analysis grid to make sure that our biases didn’t play into deciding what the best solution is. I don’t have an actual screenshot of the artifact or from the user-testing process, but what we did was talk to the customers whose problems we had documented in the first phase and got back to them with “hey, remember that problem that you reported 1 year ago? We have a possible solution. Wanna participate in a 30’ test session?”
- Finally, after a couple of iterations, we came up with a solution which we described in two ways. An invision click-through prototype which showed the high-level interactions of the feature itself and a story map which described all the touch points before, during and after the usage of the feature by a user, such as onboarding, documentation, showing status in other screens. By the way, he solution was nothing like what every competitor is doing, which is providing different content stages, but we provided a smaller and more flexible unit of work which solves the core problem but allows more versatile use cases without blocking the flow: Tasks. This was spot on aligned with our vision of content automation and we couldn’t have gone with the traditional workflows steps if we wanted to offer the programmatic flexibility that we wanted with that traditional feature.
- Finally, this is the last step of the process and the longest and most expensive one. Here the entire team is involved in delivering the feature, working in Scrum and...there’s not much that a PM can do here. Maybe, depending on your organization you might have to put on your Project Manager hat here.
- Now, you might be wondering if this is waterfall. “Aren’t we supposed to be working together, developers, designers, POs?”. “Are we not generating too much waste?”
- Well, here it depends on what you mean by “working together”. If it is about the entire team working into the discovery phase by running workshops, talking to customers, synthesizing interviews, then HELL YEAH, definitely work together - this is also encouraged by our Scrum sages who suggest we get rid of titles within the team. Mind you, we are talking about the activities that are defined in the first 3 parts, though, not the last part, and you know why?
- If we were to map the process into a time axis, the shapes would be skewed like that. Because the investment that you are going to spend, even if your entire team is working on these, is completely disproportionate with the cost of working on the 4th step.
- If you jump as a team right into the delivery phase based on a senior executive’s gut feeling, a well-intended support coleague’s reported customer problem, or a direct ask of a PM without having done your due diligence, I guarantee you that you will have gaps in your understanding and will have to stop and restart so many times that in the end your developers will give up and be like “just tell me what you want me to build and I’ll do it”. Problems transfer easily, solutions don’t.
- This is what “tell me what you want me to build and I’ll build it”. Disengaged teams and not stupid people are the ones who make funny meme-generating mistakes like that. And usually it’s these kinds of teams that smart developers are quitting.
- One last thing: I’m not advocating against agile practices or Scrum work-together like frameworks. In the delivery phase it makes a lot of sense to not get far ahead in terms of specifications and release and test fast. It’s this back n’ forth between discovery and delivery that is expensive.
- Now, I wanna talk about innovation a bit. Innovation comes by differentiating enough from your competitors to offer something that is better or cheaper and, maybe this doesn’t come as a surprise to you, but it’s almost never because you are building a product right, but it’s because you’re building the right product.
- We see this in every kind of consumer products, like the iphone and all the smartphones that followed after it. See how they all copy the disruptor by doing the same things but choosing a random attribute to get “better”, like “more memory”, “better camera”, “bigger screen”?
- And I’m not throwing shade at these products. If you have tried any of them, like windows laptops, you know that they are amazing products. They work well, they are fast, strong, greatly build, with keyboards that don’t fall apart ;).
- The point is that these disruptors asked the right questions, such as: “How do I make the user interface intuitive?” “How do I make this machine more durable?” “How do I make this car oil-independent while safer and faster?” Which are questions that also users were asking. They didn’t focus on what they could build better. What they could make smaller, faster, bigger.
- And the place where you ask these questions is here. It is very important and hard to find the right problem to solve but you only do that by talking to people and trying to be as unbiased as possible.
- Here it is too late. If you start challenging the problem you are solving or if you come up with a idea that would solve another problem, it is too late to find it here. It’s not impossible to shift course, but it’s gonna be expensive.
- Here’s another schematic about course-change. Let’s say that you want to land somewhere and this is where you will get by, not doing anything. But you want to land up there, because this is your company or product vision that you believe will help you sustain a business, create a new market, anything.
- With a certain amount of effort you might be able to get there. If you change course early enough you will be able to achieve your desired impact
- If you applied the same amount of effort late in the process, where for example you started to build a solution for your wrong problem, then you would really have to spend a lot of effort not to land in the wrong place.
- This is very important and I want to drive this point home. We often focus a lot on tactical activities such as roadmaps, prioritization exercises, agile delivery activities...these are all important parts but there is also a reason why you see medium articles, linkedin statuses, talks and workshops around these activities: they are relatively easy to teach (maybe not to apply but that’s another story). The hard part is to find the right problem, to discover (to remember Cagan’s definition) a valuable product.
- Our responsibility as PMs is primarily the strategy of the product. If we lose sight of that or are stripped of this responsibility then we are really not offering the value that we could be offering to our organizations.
- You might have seen this article of Product vs Feature Teams. It talks about empowered teams that tackle problems themselves without being dictated the solution by senior management. This is where you want to be, how you want to build your teams and how you will attract top talent. And this framework will help you get there, but of course it’s not the only thing you need. That’s something that touches upon Product Leadership and would be the topic of another interesting talk.
- It might sound like a sketchy Ponzi scheme but it is actually an existing framework which has been adapted by my smart colleagues at Contentful into a Product Process. https://www.designcouncil.org.uk/news-opinion/what-framework-innovation-design-councils-evolved-double-diamond
- We used this tool to keep track of customer feedback in order to help with the first problem exploration phase and with the prototype user testing phase.