The very word Discovery does inflict a thought of finding something and this blog attempts to do nothing different rather within the boundaries
of business problems irrespective their quantum. In order to have a better background of Discovery it is important to start with Design Thinking
A simple preface on Design Thinking
Design Thinking bears quite a lot of definitions on the internet and it isn’t too difficult to make sense of them with a quick read through.
But the common misinterpretation is to term it as a ‘process’. This is where I differ and strongly believe Design Thinking is a ‘mind-set’ that
combines empathy, technology and innovation. The immediate question is how do you realise this mind-set? Here is my take on it. I do agree that we
need tangible ways of realising mind-set which we can simply call a process for now. At the same time the process cannot be rigid or too complex to
make it terrifying to use. So this where we can adapt a 3-step process that will foster the Design Thinking mind-set in solving business problems to
keep it quick (time boxed), simple (not too many steps) and flexible (customisable to different needs).
Let’s focus one at a time
This blog will focus on the Discover phase and bring out my perspectives of how it can be used and the benefits it will surface. To set the boundaries
with clarity – Discover phase starts with the problem area and runs through to the point of defining the problem and bringing together the key elements
around people, value and expected features. Anything beyond this is such as ideation, prototyping and validations are not part of this phase and often
there is a tendency to spill them into this (Caution!!!).
Three key fulcrum points that make the Design Thinking approach effective are
(i) User Desirability
(ii) Technical Feasibility
(iii) Business Viability.
User Desirability aims at having solutions that solve real-time problems that the users face and desire to fix, Technical Feasibility focuses on doable,
scalable and repeatable solutions and Business Viability is more towards getting money for the solution. During the discovery phase it is important to deep
dive in understanding the problem and collecting the required inputs in achieving the sweet spot between the three fulcrum points which we shall term as
‘Minimum Viable Product’ (MVP). A minimum viable product addresses the most critical and must have needs that will solve the problem at hand.
Other needs outside of this will become part of the ‘Feature Roadmap’ enabling continuous improvement of the solution. Refer to google examples on how to
develop MVPs and you will bump into as many as a few hundred examples that are relatable and understandable.
Why Discovery phase?
In the agile world it is imperative to be adaptive to pivot constantly that will calibrate you towards achieving the sweet spot between
the fulcrums of Design Thinking but at the same time you need something to start with. During a Crime Scene Investigation you would have
heard of first information report which brings out the knowns and aids in identifying the unknowns further. Discovery phase is similar to
that and sets the kind of skeleton to start ideating the solution. Discovery phase targets to surface the problem and its ecosystem in a
more structured manner. It is the first lap of a race and if you can achieve a lead pole position is not too difficult to achieve.
Elements of Discovery Phase
The key elements are Scope, Stakeholders, Pain Points, Value Statement and the Feature backlog.
- **Scope: ** defines the guidelines, house rules and the ones that are not be touched
- **Stakeholders: ** people are the crux and includes the problem facers, the ones who interact with the problem and the ones who will be
resolving the problem
- **Pain Points: ** current day troubles and needs that are either taking up effort, time or cost in most of the business problems
- **Value Statement: ** writing down stuff is always difficult for me but when I do that is when I am able to identify the burning platform and the benefits.
Value statement is the same, you need to write down what solving the problem brings to you and the ecosystem is when you will get closer to solving the exact problem
- **Feature backlog: ** Often we have the tendency to go for more than what we need but that does come with some cost (not just monetary cost).
So better to define what you need now, what you might need later and what might be a luxury for you with regards to the problem
How do we get started?
All we need is a beginning. The moment you realise the need for a solution – Relax! Plan a discovery activity and bring together different minds that
can contribute to it. You will need your users, design experts, domain experts, decision makers and technology ninjas. But don’t stop with them if
you think there are others who can contribute. Plan for a collaborative activity for at least a couple of days (a week is generally better).
Set a goal for each day to address one of the elements listed above. Time-box your session and hear out all of them participating. Take notes for each
session and discuss/argue to put forth validations of the points to ensure we are being critical of them to achieve best results. Wear different hats
to question and answer different perspectives to pick the most aligned ones. And the end of each time-box, take some time to document the outcomes and
allow them to be consumed by participants for any corrections or updates.
Wait, I am missing something here – Oh yes you will need a facilitator to keep all of this in a nice and seamless way. But the facilitator doesn’t
need to be superman/superwoman rather someone who can keep the focus on each of those elements and bring consensus based on evidential information.
Exemplar of 3 hour Discovery Workshop
Hope I have kept it open ended for me to run through with the series :)
Please reach out to me Bharath.Sabesan@roll-royce.com if you would like to have a conversation around this.
I am better at voice blogging!!! (if talking through can be called so)