Download to read offline
Uploaded bySigma Software
Max Kunytsia, “Why is continuous product discovery better than continuous delivery?"
Max Kunytsia emphasizes the importance of continuous product discovery over continuous delivery, highlighting key aspects such as value, usability, feasibility, and viability that product teams must address. He shares insights on customer engagement and research techniques to ensure solutions meet real needs, citing examples of failures due to inadequate understanding of user problems. Kunytsia concludes that ongoing iteration and improvement are vital in product management, supporting the idea that well-defined problems lead to effective solutions.
More Related Content
Similar to Max Kunytsia, “Why is continuous product discovery better than continuous delivery?"
More from Sigma Software
Max Kunytsia, “Why is continuous product discovery better than continuous delivery?"
- 1. Why is continuous productdiscovery better than continuous delivery? Max Kunytsia, Director of Product 22.06.22
- 2. 3 2 EVERY PRODUCT TEAMNEEDS What about someone who drives continuous product discovery?
- 3. ABOUT SPEAKER 3 Max Kunytsia ●Almost 15 years experience in technology industry (yep, I’m that old :D ) ● Started as frontend engineer team lead project manager, and… ● Finally switched into product management, which I’ve been doing for last 7 years ● Last 3 years @ iDeals as a Director of Product 3
- 4. PRODUCT DISCOVERY →PRODUCT DELIVERY 3 4 Product Delivery Product Discovery Find. Build.
- 5. Product discovery mainquestions
- 6. 3 6 QUOTE #1 A problemwell stated is a problem half solved. Charles Kettering Head of innovation @ General Motors (1920-1947)
- 7. 3 7 PRODUCT DISCOVERY MAINQUESTIONS VALUEBILITY USABILITY FEASIBILITY VIABILITY
- 8. 3 8 VALUEBILITY QUESTION TO ANSWER Dowe know customers' real problems and are they willing to pay us for solving them? ● Talk to customers weekly ● Live in behavioral data ● Jobs-to-be-done and User Story Mapping techniques ● Know your customer, but avoid “curse of knowledge” ● Validate and test your assumptions
- 9. 3 9 USABILITY QUESTION TO ANSWER Canusers figure out how to use the solution? ● Establish relations with customers ● Create wireframes & prototypes: high-fidelity / live-data ● Prepare scenarios and tasks ● Avoid leading and quietly observe ● Avoid “falling in love with the solution”
- 10. 3 10 FEASIBILITY QUESTION TO ANSWER Canwe build the solution with the money, time, skills, and technology we have? ● Find the right technology / approach ● Allow engineers to create proof of concepts ● Don’t forget about dependencies and tech debt ● SSPM: Security, Scalability, Performance, Maintainability
- 11. 3 11 VIABILITY QUESTION TO ANSWER Doesthe solution also work for the various aspects of our business? ● Always think about outcome and metrics ● Know and tackle stakeholders concerns ● Keep stakeholders informed and involved ● Align with strategy and funnel
- 12. 3 12 DOES OUR SOLUTIONBRING NO HARM? VALUEBILITY USABILITY FEASIBILITY VIABILITY ETHICS
- 13. Product discovery successstories
- 14. Product discovery successfailure stories
- 15. 3 15 QUOTE #2 Joshua Porter Partner@ Rocket Insights 1 hour of research saves 10 hours of development* time. * design, analysis, refactoring, etc.
- 16. Technical details ofintegration with the current permissions model and storage were missed. MISTAKE MISTAKE COST 50%+ to initially estimated efforts. ?` FAILURE STORY #1 3 16 USER PROBLEM Don't disclose sensitive information to 3rd party | Redaction, as spies do VALUEBILITY USABILITY FEASIBILITY VIABILITY 20+ uses interviews Tests with prototypes Proof of concept 50+ lost deals. MMR* * minimum market requirements
- 17. Didn't ask enough"whys". Turned out that need was not only to structure files, but also to have an approval workflow. MISTAKE MISTAKE COST Low, 13% adoption rate. Unnecessary day and weeks spend for analysis and additional development. ? FAILURE STORY #2 3 17 USER PROBLEM Structure documents in several dimensions | not only via folders; labels/tags VALUEBILITY USABILITY FEASIBILITY VIABILITY Five enterprise customers Reference customers Implemented as customization Enterprise is the target market
- 18. Project-based approach vsContinuity
- 19. 3 19 QUOTE #3 Teresa Torrer Productmanagement coach Digital products are never done. We can always iterate and improve.
- 20. 3 20 PRODUCT DISCOVERY →PRODUCT DELIVERY Product Delivery Product Discovery Find. Build.
- 21. 3 21 CONTINUOUS DISCOVERY ∞CONTINUOUS DELIVERY
- 22.
- 23.
- 24. 3 24 “A problem wellstated is a problem half solved.” “1 hour of research saves 10 hours of development time.” “Digital products are never done. We can always iterate and improve.” KEY TAKEAWAYS
- 25.
- 26. Thank you foryour attention and have a good evening ;)
Editor's Notes
- #2 Hello everyone! Happy to see all of you and thank you for sharing this evening with us. Today we will talk about product discovery and why you should invest in it as much as possible.
- #3 But before the start I wanted to share a post in linkedin which I saw a few days ago. Post was about personalities in the product team. As you can see according to the post each team needs: - Someone who is always pushing the strategy, because correctly defined direction is a foundation for everything - Good strategy needs a good tactic and operations or in other words someone who sweats the details - When we know what to do we need someone who ships a ton - And, finally after working hard we should pay hard and someone who loves to coordinate team events When I took a look at the comments under the post I saw that the most popular comment was about a quite relevant topic: What about someone who drives continuous product discovery? And, in the next 30 minutes I will try to explain why product discovery and especially continuous one is so important for the success of any product.
- #4 And another “before the start” thing – a few words about myself. My name is Max and I have almost 15 years experience in the technology industry (yep, I’m thad old :D). I started as frontend engineer then became team lead, then project manager, and finally got myself into product management, which I’ve been doing for the last 7 years.Three from those seven I’ve been working as a Director of Product at iDeals. Together with a team of 20 product managers, designers, and data analysts we are trying to build the best virtual data room for M&A and fundraising transactions. So if you will be doing another round and investors will push you into due diligence don’t forget to ping me on Linkedin ;)
- #5 So, Discovery and Delivery. Those two activities are always present in the product development life cycle. In some cases Delivery can be more clearly defined and even described in development policies, but Discovery will be still in place even if you don’t call it so. If we will simplify the definition for both terms as much as possible then probably we can use 1 one verb for each activity – find for Discovery and build for Delivery. The Discovery part is all about customer problems and solutions for them. In terms of discovery, we should find another problem to solve, understand how important it is for customers, and align it with our strategy, i.e., understand if the possible solution works not only for the customer, but also for the business from different perspectives – technology, marketing, legal, security, etc. When we know what we should build, why, and how the Delivery part takes the place and aims to provide customers with reliable, scalable, and robust solutions.
- #6 We will not talk about Delivery in details, I bet all of you know everything related to requirements, development, testing, and releasing. We will focus more on Discovery and what exactly you can do to have as much confidence as possible before you switch to Delivery.
- #7 I am sure this phrase is not new to you. It is attributed to different people, with slight variations. I prefer to think about Charles Kettering, head of innovation at General Motors, as an author of this phrase. And, though he, obviously, didn’t say it about digital product development it’s still extra relevant for us or any other industry or even just your day-to-day life. It is indisputable that defining a problem well is essential to enable solving the problem with a positive impact. And, to define a problem well you need to unpack all underlying questions, define the outcome, understand stakeholders, find possible solutions, and finally understand if you really can solve the problem with your resources.
- #8 And, all those activities in case with digital products can be described in four really simple categories: Valueblity, Usability, Feasibility, and Viability. The names of the categories speak for themself, but let’s talk about each category in detail.
- #9 I bet you can find dozens of problems that you can solve for your customers, you can get even more feature requests from your customers, but you cannot do all of them. And, here VALUEBILITY comes into play and helps us to answer a question – Do we know customers' real problems and are they willing to pay us for solving them? To answer this question you need to know your customers. You need to speak to them weekly, you need to live in behavioral data, conduct surveys, launch focus groups, perform demand testing, etc. and use all insights from those sources to understand what you can do. To simplify problems visuzaltion you can use different techniques, for example, Jobs-to-be-done or User Story Mapping. Two more things worth mentioning here: the first one about the so-called “curse of knowledge.”, when at some point of time you will start to think that you know everything about your customers, that you became an expert in the domain. And, I urge you to never get into this trap, it leads to failures and features that nobody actually needs. The second one is that all problems or jobs-to-be-done or assumptions should be validated and tested based on quantitative or qualitative data.
- #10 And, talking about testing. You should spend enough time not only to challenge the problem to solve, but also the solution. You need to get an answer to another question – Can users figure out how to use the solution? Answering this question you can create wireframes, high-fidelity or even live data prototypes. You can prepare scenarios and tasks for users. And, find users for tests. This can be a challenging part, especially in B2B, so think about this ahead. You need to build relations with your current or target users, show them that they can influence the product that they use or give others incentives such as discounts, gift cards, etc. This can be done by establishing small communities, building 1-1 personal relations, using linkedin outreach or any other way that works for you. Same as for Valuebility I would like to highlight two important points here: when you already jumped into the test try to listen more and avoid leading the user. Sometimes it will be hard, because you already fell in love with your solution and you think it’s perfect, but try to be as unbiased as possible.
- #11 When you already have validated design time to understand how to build it. In terms of FEASIBILITY you need to get an answer to: Can we build the solution with the money, time, skills, and technology we have? You can start with understanding what technologies you can use. When you get it, allow engineers to create proof of concepts. You can even test those concepts with your customers if they will have a good enough feel and look. Obviously you will have different kinds of quality attributes, but I want to highlight the most crucial quartet: Security, Scalability, Performance, and Maintainability. A special note for mature products: never forget about dependencies and technical debt. You can find great technology, create breath-taking proof of concept and then fail on integrating it with your 5 years spaghetti-coded product.
- #12 Finally, you need to understand if the solution works not only for customers, but for the business. Does it allow us to achieve the desired outcome and push the target metric, for example, increase lifetime value or decrease churn? You need to know stakeholders, their concerns, and fears. Maybe the legal team always worries about privacy and GDPR, while the marketing team cannot understand how to promote the new feature? Security, sales, compliance, finance, customer success, and all other teams should be at least informed and in some cases involved in ongoing discovery and delivery. Last in the list, but probably first in your to do checklist for the discovery: align with strategy and the funnel. If you are targeting SMB with a 50$ check and you are creating a really complex far away from self-service model solution then you will have issues. Even if the solution solves problems for your customers they will struggle to use it without on-boarding and demos, which you cannot afford for SMB with less than X$ per check.
- #13 Normally, we would consider ethical questions as part of business viability. If a solution is not ethical, it may indeed leave the company in serious trouble. In practice, however, there are two problems with this: First, as we already discussed there are already so many different aspects to business viability and it's easy for ethics to get lost. Second, unlike the other areas of business viability, there is rarely a stakeholder explicitly responsible for ethics. The result is that ethics too often does not get the attention it deserves, and we have all seen the damage to the company, to the environment, to our customers, and to society, which can be done, so don’t forget to ask yourself: does our solution bring no harm?
- #14 To demonstrate you how correct questions during discovery help you to deliver the best possible product I initially thought about sharing some success stories. But everyone talks about success, so where is fun to talk about it again?
- #15 Let’s talk about failure stories that we had at iDeals and I hope they will help to avoid the same mistakes.
- #16 Before we will take a look at several failures, I want you to embrace the quote “1 hour of research saves 10 hours of development time” from Joshua Porter, Partner @ Rocket Insights. Obviously, this equation is not scientific, but each solution costs time to build and when you already delivered it and it doesn’t work for users you will need to perform an analysis of what is wrong and afterwards rethink, redesign, and rebuild the solution.
- #17 And, now when you know the equation let’s take a look at several examples of how the equation works.
- #19 Most of us grew up in a project world. We are programmed to think about everything as projects with beginning, a middle, and an end. In digital products we typically mark a project as finished once we release code to our production environment. Most of these projects are framed in the solution space – they take the form of “build this feature” or “launch this program.”
- #20 However digital products are never done. We can always iterate and improve. Google, Facebook or Netflix will never be finished projects. For example, Netflix started as a DVD-by-mail service, iterated to streaming movies, and now creates its own original movies and TV series. We can always create more value for our customers and based on it get more value for our business.
- #21 While there’s nothing inherently wrong with a project-based approach when you do Discovery and then Delivery, it’s not sufficient for teams who continuously ship value to customers.
- #22 The key idea is this simple: If we are continuously making decisions about what to build, we need to stay continuously connected to our customers, so that we can ensure that our product discovery decisions will work for our customers. And, also we should deliver those decisions and solutions to our customers, so we need to stay on two tracks: continuous discovery and continuous delivery. Discovery track is all about continuously and quickly generating validated product changes, and the Delivery track is all about generating releasable software.
- #23 Certainly, at any given point in time, different people on the product team may be focused on discovery activities or delivery activities, and obviously the product manager and product designer spend most of their time on discovery, and the engineers spend most of their time on delivery. But to generate innovation we want we should involve each member of the product team in both activities. This shift in mindset often gets referred to as “product thinking” or as a “product mindset.”
- #24 Time came to summarize everything that I tried to tell you. And, I would say that to cover all details of discovery and delivery tracks we need ten times more slot than 30 minutes, but I tried to highlight problems for you, so you can continue your own discovery.
- #25 My key takeaways will be quite simple. If you want to know how to solve the problem you need to understand it as well as possible. To get this understanding, spend enough time before jumping in development, always keep in mind equation 1 to 10. And, last, but not least – never forget that you are running not 100 meters, but laps and they are countless.
- #26 If you want to get more information and build a strong culture of continuous discovery-delivery in your organization I suggest taking a look at books from the slide. Some of them such as Lean Startup, Crossing the Chasm and The Four Steps To the Epiphany already became classics. With Hooked you can better understand how to ask “whys” questions and then with insights from Sprint understand how to test even big ideas in just 5 days. And, finally using jobs-to-be-done technique and embracing continuous discovery habits you can truly make your product teams empowered and achieve extraordinary outcomes :)
- #27 That is it for today from me. Thank you for your attention and have a good rest of the evening ;)