Although theory sounds really intriguing, the examples of teams that have actually implemented relative processes are scarce. Through this post, we will showcase an actual framework that could help incorporate a continuous Product Discovery approach into an Agile team, through deep-diving into 3 core aspects: engage the team, listen to the user, involve the stakeholders.
Engage the team
Product discovery is first and foremost a collaborative process, so the whole product team should be involved. Set some discovery sessions, where the team could cooperate through the product discovery cycle. This cycle could be defined as:
1. Identify business problems
This could take some time to be established. Ideally, the product team should not receive feature ideas, but business problems that need to be solved. Usually, teams already have a backlog of potential solutions, so in the beginning, this step might be skipped. As the team evolves, though, it will be able to recognize the problems and create relative solutions.
2. Ideate on potential solutions
Taking a specific problem and ideating solutions to tackle it. Workshop exercises like Brainwriting, Mindmaps, Negative brainstorming, Mash-up, Round Robin or even Hackathons could be utilized.
3. Frame the idea
Setting the actual context together with the team, on what the business objective is, what does success mean, what problem we are trying to solve and which is the target market. The startup canvas or the opportunity assessment technique are some of the exercises the team could take advantage of.
4. Set the discovery context
Setting the foundation of the idea, through exploring the current flow and where the idea could fit or other best practices. At this step User Story Mapping, Competition benchmarking or some Lightning demos could do the job.
5. Visualize the idea
Some quick prototyping is important for the whole process. It could be low fidelity with very low thinking applied. The aim is to iterate rapidly through some options and end up with a testable prototype. Depending on the idea the crazy 8s or any other design session could prove valuable.
6. Conduct user research
Build a research bucket and be able to test your solutions. This could be the inclusion of the prototype at the end of an interview session or any other research method seen as fit (eg. card sorting, unmoderated usability testing, first-click tests). All could run asynchronously during a sprint.
7. Define feasibility & value
Feasibility refers to aspects such as: do we know how to build this, do we have the relative skills, will it affect our performance, do we miss some infrastructure? Apart from this, confronting all these aspects will offer a better overview of the actual effort estimation needed to deliver this potential feature.
Business value is an outcome of all the previous steps, as it includes summarizing the information collected and moving on with some assumptions on how this idea could affect the business drivers. Will it bring some more revenue, remove manual work from internal teams or satisfy the customer? And if yes, how much?
Listen to the user
Users are the ones who will, in the end, decide whether a product is labelled as successful or not. Keeping a continuous incoming flow of their feedback can prove vital for a product. Product discovery is fundamentally based on this feedback, as it helps the team members empathize with the user and build a more complete perspective.
Each product team should establish a specific number of interviews that will be run at all times, regardless of whether there is any feature to be tested. Set some automated participant captures, book specific timeslots and try to run at least 2–3 user interviews per week. Include all team members in the process, at least as observers in the beginning. The utmost goal is to engage them and end up having an engineer even moderate one of the interviews. This continuous feedback loop could enhance the product development process in multiple ways:
- The team builds empathy with the users.
- User problems/issues are communicated to the team, which then can move onto ideation for the most important ones.
- Interview sessions could also serve as a placeholder to include some quick testing of the rapid prototypes created for some features.
Involve the stakeholders
Stakeholders are the ones who can transfer some crucial business/department information, that could set the context of a potential problem or idea. They are a very important part of this and should be highly engaged with the whole discovery process. The ideal way to involve can vary, as each team and each feature might have different ways to approach this. Some options to achieve this could be:
- Set a discovery demo: a session to showcase the problems under exploration, their context, user feedback, some design prototypes or anything else related, seeking to get feedback from the stakeholders.
- Set synchronous meetings on-demand: when you need the feedback, set a meeting with the stakeholders and showcase the information collected.
- Set asynchronous communication: emails, chat messages or any other way to present findings and get feedback at any time.
- Invite them to some of the team discovery meetings.
Last but not least, all these need to be settled within the current flow each team follows, ensuring that it will not disrupt the implementation velocity. An average agile team has specific meetings, like Planning, Grooming, Demo and a Retro. An example of how the discovery framework could be incorporated within a 2-week sprint is shown below.
Discovery meetings will be utilized towards moving problems & ideas throughout the product discovery cycle. Some of the cycle steps, like research or prototyping, can, of course, be run asynchronously and not during these meetings. It is important, though, to bring the outcomes within the meetings and generate insights. User interviews will continuously bring feedback and enlighten the team perspective, while discovery demos (or any other sort of communication) will bring the stakeholders closer.
The team could plan on a quarterly basis and select for example 8–10 problems that will enter the discovery cycle and be explored. The end product of each problem that enters the process will be a feature that:
- Is tackling the problem efficiently.
- Has low-fidelity designs already been tested with users.
- Incorporates business & stakeholder feedback.
- Has been evaluated against what it will bring as value to the business.
- Has been estimated towards the engineering effort needed to implement it.
At the end of the quarter then, and before the planning of the upcoming one, the team will have 8–10 defined and evaluated features. An algorithm to score the value each one will bring to the company at the given time vs the effort needed to implement it could produce a score that will be utilized towards the prioritization of the most valuable features. There are also services/software that can assist the organization of this feature backlog and its scoring.
Depending on the team capacity, the best scoring features will be picked and planned for implementation within the upcoming quarter. In the next quarter, as a result, the team could for example implement 3 features, explore 8–10 additional problems through the discovery process and continue expanding the evaluated items backlog. In the long run, the team will have a satisfying amount of scored ideas, all of them valuable, usable & feasible, while being able to prioritize the ones that would bring the optimal value to the business.
A very important part in the establishment of this process is to educate anyone involved, from the team members to the company stakeholders, towards this discovery framework and how feature prioritization will work from now on. Involving people in the analysis of a potential problem could create the impression that this will be tackled immediately. Although, discovery offers the option of tackling only the most valuable ones, which means that a feature might stay for a long time in the backlog if it scores low.