There’s more than one type of Discovery – find out which is right for you
Discovery is a way to understand what the best problem to solve is and identify the most valuable ideas to progress, in order to reduce the risk for what you choose to invest in during the design and build.
We recommend approaching a discovery from three key angles – Desirability, Viability and Feasibility. We’ve seen this result in a more robust outcome that teams can feel confident taking forward.
However discoveries take all different shapes and are set in different contexts, and can be useful at different stages. The recommendation above applies well when evaluating new ideas for example. Understanding what you want to get from a discovery is the first step, what is it that you hope to learn?
In this article I will explore some different types of discovery including:
- Strategic Discovery
- Value Proposition Discovery
- Product Discovery
- Feature Discovery
to look at why we do discovery, what we do and who is involved.
A strategic discovery can be helpful if your teams lack alignment and direction about what to do next and how to get there. This could be in relation to changes in the market, a need to move reduce operational cost or a desire to grow and improve. By understanding your own problem space and collaborating to uncover challenges and opportunities, it’s possible to find clarity.
Scenario: we have a long running, successful service for our customers and now want to increase sales, introduce digital tools for operational staff and improve our customer experience.
- Strategic Discovery would explore the current ‘as is’ situation, reviewing the existing customer experience and identifying pain points and opportunities. By understanding users and their needs, we use this insight, as well as stakeholder feedback to explore the problems to solve and visualise an ideal experience to act as a ‘North star’.
- In Discovery, interviews with employees would consider their current workflow and highlight ways that digital tools could help and provide a better experience when completing tasks. It is likely to include a review of the current technical architecture and platforms.
- Competitor research can provide a broad view in discovery of what others are doing, to understand the market direction and take inspiration or define how to stand out. Identifying clear KPIs to measure would be included.
- Discovery would examine the sales pipeline from start to finish to understand the multiple touchpoints and channels a customer might engage with before converting. Customer feedback and engagement data can provide insight into where the opportunities lie.
A strategic discovery would be led by a product manager, user researcher, service designer and technical architect, with engagement from other business teams and senior stakeholders.
The outcome of this strategic discovery would be a clear, shared vision and set of outcomes that the business can work on together to achieve over time. During this process the main enablers and functionality required this would be identified. This would show the role different teams might need to play across the organisation, from operations to digital to marketing to legal.
Value Proposition Discovery
A Value Proposition discovery is well worth considering if you have a new business idea and want to evaluate it. It’s a chance to explore how commercially viable it might be, do your users want it, is the time right, and what will it take to build and maintain it. Discovery helps you test your hypotheses and drastically reduces the risk in progressing. There are no shortage of ideas out there, however choosing the most valuable idea to progress right now is the hard part.
Scenario: we have an idea for a new value proposition that we hope to bring to market. We want to create a subscription service for customers and increase customer retention.
- Discovery would include looking at subscription engine products, integration and licence costs. As well as fraud and risk management, data governance and security, teams would also want to explore operational support and technical readiness.
- Discovery would involve research – competitor research to review how others model their subscription service and what their offer is to customers. With customer research to understand what problem we are trying to solve, as well exploring expectations, behaviour and needs in relation to the new service.
- Discovery would include working with finance, legal, operations, customer services and trading teams to explore price points, costs and business viability of the proposition design. Service designs would visualise how different teams would deliver a service like this, exposing complexity and dependencies early..
- Discovery would be a time to pilot the idea with customers and employees to test and learn what works and what needs refinement. This might include conducting technical spikes and creating proof of concepts to test assumptions, this will de-risk the technical approach as well as ensuring a great customer experience.
This type of discovery would be led by a product manager, user researcher, service designer, working closely with a UX designer, an SME and a technical architect, with engagement from other teams in the business and decision-making from senior stakeholders.
The outcome of this type of discovery would be for the business to be able to make a confident go/ no go decision about a new proposition, with a clear understanding of the investment required, dependencies, the time to market, the customer behaviour expected, and the teams needed to deliver this proposition.
The Value Proposition Discovery approach can also be applied when levels of engagement are lower than expected for a product you’ve already created, or users aren’t engaging as expected, resulting in a lower completion rate or low ROI. The temptation might be to keep adding more features and continue in the hope that users will eventually come; another approach might be to kill the product altogether and walk away.
In our experience, pausing and spending time with users to understand their broader needs and get feedback on the product that exists today is a useful step. Feedback is invaluable and no matter how brutal it may be, it provides a much clearer view of how the product is perceived and used today. Research can uncover what’s missing, where the friction is, whether it solves a real problem and why users might be choosing to go elsewhere. Armed with this insight, teams can make informed decisions to change direction and re-imagine their product, remove it, or target a different user group.
In our work with a government department, we ran a discovery to understand why the uptake of a free health related service was so low, despite the investment it had received. Conducting a broad discovery, we spoke with the target audience to understand how they access similar services; this included the providers of the service and those who fund and procure services across the country, to understand how the current service operates. Our focus was on awareness and access – sometimes you can create a great thing, but if no one knows about it, or it’s hard to access, they won’t be able to use it. We were able to make 5 key recommendations enabling the policy makers and government team to move into Alpha with ideas to test and measure.
Adding new functionality to an existing product is what keeps customers happy and enables the business to respond to change. To avoid a solution being applied to the user experience based on assumption, a short discovery will ensure that the new feature is well designed, simple and easy to use, doesn’t negatively impact other parts of the user experience and adds value. It’s all in the detail.
Scenario: we want to introduce account functionality to our customers to help us connect with our users, make relevant products and services available, and provide a place for them to manage their details and save preferences.
- Discovery would be to understand what the user needs are for the account, what are their expectations, and their current behaviour based on other accounts they have online (e.g. be able to use social log in or 2FA). This would also be a chance to conduct competitor research and analysis to provide insight on trends.
- Discovery would include understanding the software and technical choices for running customer accounts (data protection and governance, authentication etc), conducting technical spikes or creating proof of concepts.
- Discovery would identify the KPIs and business needs that the account functionality would serve and how we would measure this.
- Discovery would provide a chance to explore a range of ideas and prototype the user experience to gather feedback quickly from users, testing any assumptions about the journey flow, content and interaction. A prototype also helps everyone have a shared view of how the new feature will behave and what the interaction might feel like.
- If any existing account functionality exists, via a third party for example, then we would also consider the migration approach, how to move existing customer data and communicate clearly with those customers moving to a new account.
This type of discovery would be led by a product manager, user researcher, user experience designer, content designer and technical architect, with design walk throughs and research playbacks for stakeholders.
The outcome of this type of discovery* would be to agree the scope and requirements for new functionality or a new feature to be built, and have high confidence in the user experience design. From here the backlog can be created and development work can begin, knowing that we are building the right thing.
* In a UK government setting, this work would span discovery and alpha phases, with development happening in Beta, into Live. Outside of government, this is all discovery, going into delivery.
At the Co-op, a major UK retailer, we designed and built an employee tool to manage rotas, including sickness and leave, replacing the paper based process that existed before. We spent time with employees in shops, including shop staff, shop managers to understand their environment and current ways of managing shift rotas. We used prototypes to ensure the new tool met those different user needs and designed an inclusive experience that was easy to use. Investing in time with users, led to 85% voluntary adoption of the tool across 46,000 employees in less than 6 months.
By investing in a strategic discovery, you ensure that as an organisation, there is a shared view of where you want to get to and why – you have the bigger picture and direction. This in turn informs the teams across the organisation and provides the alignment so often craved for, joining the dots. The teams can then discover how to release products and features that provide the most value and solve real problems. Before a shorter discovery to explore the best way to design and build experiences to meet user needs, and deliver successful business outcomes.
Over time, stable product teams would be doing continuous discovery alongside continuous delivery to keep their product up to date with new features and functionality, and perhaps more importantly, continue to adapt and to respond to change. More on this in a future post.
Conducting discovery at these different stages will ensure that you design and build the right thing with confidence. If you are considering running a discovery of any kind and think we can help, please get in touch.
Over the past few years, running inceptions has become the default pattern for kicking off new development initiatives within Equal Experts.
We find that running inceptions offers the team and the wider stakeholder group a foundation from which to kick off a new piece of development, which gives it the best chance of being successful in the months that follow.
When we first started formalising the inception process, we found that although we had many very experienced practitioners at Equal Experts, there wasn’t a consistent approach to running inceptions. Unlike earlier stages in the product lifecycle, for which tools like “Design Thinking” exist, the processes that are required to kick off a delivery still didn’t have a common language or framework.
Our Inception Playbook is our attempt to provide that generic blueprint for knowledge-sharing and inspiration, and it is a starting point for teams that want to kick off a new development initiative on the right footing.
Who it is for
Early on, we decided that we wanted to cater to a wide range of users: starting with practitioners who have never run or participated in an inception through to those who regularly perform them but want some tools that allow better planning and maybe a sprinkle of inspiration. We also felt that clients might be interested in framing what Equal Experts mean by ‘running inception’ and provide a helpful ‘leave behind’ post inception; so they can be more effective in kicking off projects in the future. This has already extended to our clients taking this as a blueprint for building their own Inception capability in house.
How it can help you
- If you have never run an Inception before, this is a ‘training’ manual to peruse.
- If you have run an Inception before, but need a refresher, this is your reference.
- If you are a seasoned Inceptionist and need practical support, the agenda, schedule blueprints, and cheat sheets are your starter for ten.
What can you expect from our Inception playbook?
Based on the feedback we have received, we believe our first public release is valuable; it has depth, relevant details and can be used both as a training document and a practical guide.
It is reasonably polished in the sense that we have done some basic copy editing and design. We have an on-screen PDF-version alongside a digital version both of which are located here https://inception.playbook.ee.
What it is about
It is worth noting that the playbook is a game plan in the sense that it is not a recipe for a single activity but an orchestration (and supporting tips, tricks and detail) of a large number of activities that altogether make up a successful Inception.
The playbook touches on topics such as
- What is an Inception, why do one and how to get buy-in into your organisation
- How to successfully plan an Inception
- How to execute an Inception
- What good looks like
- What common pitfalls and best practices are
What it is not about
Discoveries. Early in our writing, we found that there are two types of beginnings:
One is where we have a vague idea of some product or service that may provide value but are not sure about whether this is true or how this should take shape. In these cases, we would start with what we have decided to call Discovery: top-level analysis, research, hypothesis formulation and experiment to solidify the value proposition. This is very much about exploration.
Once this is clear, i.e., we have a relatively solid idea of the shape of our initiative, we now want to ensure that we are set up for success and can hit the ground running, so we do an Inception. An Inception is about validation (rather than exploration), aligning and defining (at the highest level). To be clear, we can still do all the good, lean stuff like experiment during Inception or during the actual delivery, but we will do so within the scope of delivery rather than at the level of rationale of that initiative.
In the most basic terms, Discoveries are about doing the right thing while Inceptions are about doing it right.
Our playbook ONLY covers Inceptions.
We hope you find this playbook useful. If you’ve used it to run an Inception or have feedback of any flavour, we’d love to hear from you. We offer training on Inceptions, and, of course, we are pretty good at delivering software.
Share thoughts, ask for updates, templates and other information, or get in touch if you are interested in working with us, at https://www.equalexperts.com/contact-us/