Antonis Rousounelos

A Continuous Product Discovery Framework for Agile teams

Antonis Rousounelos

Software Product Manager | Website @Blueground Co
Drag to resize
Originally posted on LinkedIn on November 1, 2021.
Go to original post.
Drag to resize
According to the Oxford dictionary, Agile is defined as:

“a method of project management used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans”.

Software product teams are usually either experimenting or have adopted some form of Agile methods, with the most popular one of them being Scrum. Moving on to a higher level, though, and eyeing a product not as just pure delivery, but as an end-to-end process, we will observe that product teams are agile in their implementation efforts while lacking an agile approach in the whole feature prioritization process.

More specifically, when working on an epic or feature, the team has a full overview of its stories and prioritizes the most important parts to be delivered first. On the other side, the epics/features themselves are rarely prioritized according to their value, as this requires further investigation & user research. This is where continuous product discovery comes into the spotlight, as it can be the initiator of an end-to-end agile product, delivering always the best value to the business and its users.

Feature delivery process

Let’s take a look at a usual feature delivery process, where we have the following steps:

1. Requests/Ideas: new feature ideas are generated through competition benchmarking, user research or stakeholder requests.

2. Feature backlog: each one of them is added to a feature backlog.

3. Prioritization: each quarter PMs pick the ones that have to be delivered and prioritize them. The assessment criteria are usually intuition, stakeholder urgency, competition etc.

4. User Research & Design: the selected features move into the next step, where the product team conducts some research and generates designs, from low to high fidelity.

5. Implementation: final designs & specs are translated into user stories and the engineering team proceeds with the implementation.

This sounds like a linear and clear path, which leads to the following facts for a product team:

  • Product teams move on into designing & implementing features that are an outcome of ideation performed by the stakeholders or the Product Manager.

  • Prioritization is based on intuition, urgency or other external factors.

  • Evaluation (what a feature can bring to the business) is usually performed on already prioritized features.

  • Research & design members conduct user studies only on upcoming features, while engineering members get informed through insight presentations.

  • Teams have product experts, design experts, engineering experts. The first two are usually considered as user experts too.

  • Success is measured on the team outputs (# of features delivered).

Product discovery

What if you tried to think of the utmost goal for a product team? Probably, delivering the features that offer the best value to the business efficiently, would be one of the first things that come to mind. The establishment of a continuous product discovery process within a product team could be the initiator towards that path.

“Product Discovery describes the iterative process of reducing uncertainty around a problem or idea to make sure that the right product gets built for the right audience.”

More specifically, it is a collaboration between the product manager, the product designers/researchers and the engineers. It incorporates continuous user feedback (internal & external), stakeholder & team members engagement, analysis, evaluations, workshops and whatever else could assist the product team to build the maturity to recognize the problems itself and iterate on solutions for these problems while ensuring that the features delivered are always valuable, usable, and feasible.

Adopting continuous Product Discovery

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?Normal text.

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:Normal text.
  • 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.


Coming back to the facts that we had previously set for a product team, let’s take a look at how they are influenced by a product discovery process:
  • 🚫 Product teams move on into designing & implementing features that are an outcome of ideation performed by the stakeholders or the Product Manager. → ✅  Teams are mature enough to recognize the problems themselves and iterate on valuable, usable, and feasible solutions for these problems.
  • 🚫 Prioritization is based on intuition, urgency or other external factors. → ✅  Prioritization is based on delivered business value.
  • 🚫 Evaluation (what a feature can bring to the business) is usually performed on prioritized features. → ✅  Evaluation is performed on all features and user research is part of this evaluation.
  • 🚫 Research & Design members conduct user studies on upcoming features, while engineering members get informed through insight presentations. → ✅  Research is conducted on a higher level (not feature-oriented) and all team members are an active part of the feature analysis & user studies.
  • 🚫 Teams have product experts, design experts, engineering experts. The first two are usually considered as user experts too. → ✅  An empowered team, with all of its members acting as owners of the product and having built empathy with the users.
  • 🚫 Success is measured on the team outputs (# of features delivered). → ✅  Success is measured on the outcome (the value that each feature actually delivers to the business).
Of course, this is just one way of incorporating product discovery within a product team. There could be various other options, so feel free to comment or propose some upgrades to the framework. You can also connect with me on LinkedIn.
Created with