Product Discovery, that is how to reply to user needs

The art of learning user needs, tools useful for product defining and creative impact of unpredictability on its shape are discussed by Tomasz Wykowski, the author of the book entitled „Scrum: jak osiągać cele, gdy wszystko się zmienia?” [Scrum: How to Reach Objectives When Everything is Changing], the only Polish Certified Scrum Trainer® and the leader of Product Discovery workshop during ABE Light 2020.

What is Product Discovery and what can be achieved by means of it? 
First of all, Product Discovery should be treated more widely than a process or a stage of work. It is rather the manner of operation of an organisation, like PR, Customer Relationship or User Experience. The entire concept is based on finding out what are the user needs and then on creating solutions that answer such actual expectations. Product discovery is based on the assumption that we do not know many things about such product or service. Acceptance of this lack of knowledge makes it possible to add acquisition of new information in the entire process of product manufacturing. It allows its improvement on ongoing basis and good preparation for and adaptation to unforeseen factors.

When sticking to an agreed plan, a team may not be able to cope with unforeseen changes. Is here the value of application of Product Discovery?
Numerous companies has an illusion that they know their user needs. According to this believe, they define the product and deliver it in a schematic and “stiffly” defined process. However, in the majority of cases they will be surprised. They find out that users use their devices differently than expected or that the reaction of the market or competitors is different than expected. They become frustrated that they have overseen something, and their plan is not adequate, it “goes into pieces”. However, if they assume from the beginning that they want to discover the knowledge, they will be able to adjust their plans on ongoing basis and make use of unpredictability for benefiting from new possibilities instead of being afraid of it.

So how to start building the Product Discovery culture in your organisation in practice?
The efficiency of Product Discovery is possible when a team searches for solutions but also deals with their implementation. It this is not taken into account; a unit will be specified within a company that communicates the knowledge about user needs to other departments. In result, the process of working out and implementing solutions will be divided, which should be avoided in Product Discovery to ensure care for the product quality. Within a team it is important that every member understands what problem is solved and what is the purpose of specific activities. It is good to ask the basis questions: What we are doing this? What do we want to achieve? For whom we are doing this, that is who is the user? What functionalities will be provided to our customers?

What tools can help us answer these questions? How to select them? 
There are many useful tools. Starting from vision creating techniques, strategy defining practices and finally to the ways to achieve them (such as Impact Mapping). We can also use user understanding techniques (e.g. persony, Empathy Maps or user stories). In the last decade, quick hypothesis testing has become very easy (e.g. A/B tests).

It is up from the team what tools are considered to be more useful. First of all it is good to think, what areas are the most risky ones and most unknown. This may include technological obstacles (occasionally) or mismatch with the market, misunderstanding of user needs or inability to fulfil them. We select the tools that make it possible to address given problems and test defined hypotheses.

How is Product Development in the context of Product Discovery?
Both elements take place at the same time. Product Development is a continuous process. After every implementation, one should quickly assess the product and improve it, if necessary. What matters is the time of response. When it is delayed, the risk of not solving real user problem will increase. If there is no feedback for a long time, you probably do what is unnecessary. Therefore, a dialogue between the members of the developing team and the product recipient is so important. The team works out hypothesis on ongoing basis, but they must be validated in the context of user behaviour.  

What traps threaten teams that want to create products in so volatile environment and in constant need of verification of assumptions and activities?
First of all, it is what was discussed above. Companies assume that know what their users want and do not verify such assumptions often enough. Something opposite may also happen, when teams “are stuck” at the stage of discover, acquisition of knowledge, or testing, because they believe they need more information. But no work progress is observed. Another problem includes pseudo experiments that do not answer to questions and hypotheses, since their result is obvious or statistically insignificant. Thirdly, in particular in smaller companies, it is often assumed that the owner, a marketing staff or developers are the best representatives of users. In result, they create a product according to the preferences of the company head although he/she not necessarily understand the user needs best.

In your work, have you been in a situation, when ordered product did not fulfil needs?
A few year ago during a Product Discovery workshop in a large insurance companies we found out that there is a large group of customers who surely would not buy the product. This conclusion required only a few hours of discussion from the development team, but made it possible to save significant sums of money that would have been spent by the company on development of a functionality for this group or on a marketing campaign. In case of another company we found out (while creating persony) that a product was not likely to have customers. In both cases we could change the direction of the product development. As the experience shows, sometimes success means not a delivery of software but saving time and money.  

So how to define the real needs of users? Is empathy the key?
The emotional layer is necessary in examination of such needs, so empathy cannot be excluded. It will be very useful during interviews with users, since they may not give direct information, so it is good to be able to read such messages. The art of asking questions is also extremely important, since they cannot be suggestive, but objective, which allows identification of true information and expectations. Instead of explaining who a given application is used, just ask the user to try to define it and describe.  

Henry Ford said once: “If I had asked people what they wanted; they would have said faster horses. So, I didn’t ask”. Product Discovery is not about question what functionalities are wanted by users, but about listening what they say and observing what they did not say, and about understanding what their problem is and how they are solving it at a given moment.

How are products discovered during the epidemic?
How have you adjusted to the new reality? We landed in a completely virtual world without an ability to work efficiently in such mode. It is much easier to discuss and generate ideas, when we can see all participants, we can write on flipcharts together, place Post-it-notes on a board. In remote communication we lose gestures, mimics and even whispers and discrete signs under the table. 

On the other hand, companies learn now quickly to be agile, and ambitious annual plans have been thrown away. Fortunately, the majority of organisations threw away their time schedules, respond to the situation and – what is important – do it at the right time. And it is Agile all about. The current situation is an important test for agility, both in the context of quick decision making, and efficiency of teams. The companies, that had earlier successfully functioned in Agile and Scrum are able to switch to remote work without significant loss of productivity.

Going a bit away from PD, how can you see Agile’s future?
The Manifesto is several years old, so maybe it is the time to update it? Agile, as the concept of agile programming, has developed constantly. The Manifesto was prepared in 2001 as the summary of achievements in 1990’s, and the development of web products gave us new possibilities. Costs of hypothesis testing, that is Product Discovery, are now much smaller than a decade ago. Of course, the definition of “Agile” terms has also changed and now it does not cover IT projects only, but also software products. Moreover, agility has entered new areas, such as marketing, sales and HR.

It will be a very interesting revolution to use Agile in hardware production, where costs of changes are still very high, and processes are rooted in the traditional approach. This change has slowly taken place already in various companies, also in Polish ones, but it is a topic for another discussion (smile).

Tomasz Wykowski
International lecturer and the only Certified Scrum Trainer® in Poland, accredited by the Alliance. The founder and CEO of ProCognita (https://procognita.pl), Agile consulting company that since 2010 has helped organisations to created incredible products and achieve results on dynamic markets. Co-founder of ALE Kraków, the second biggest Polish Agile community. Practitioner of modern business development. He has gained experience as engineer, manager and Agile Coach in numerous companies, including worldwide corporations and start-ups.

Polish version