Product Discovery defines what should be built – and why. Collaboration Is Key. Your success with agile development depends on delivering the right product requirements at the right time.
During the past few years when I have been working as Lead UX or Product Owner I have come to a core process of how to do the discovery. At my latest gig on Viaplay as Chief Product Owner I had great use of some of these methods and also found it to be a great tool to have it visualised for all Product Owners in a one pager.
Within this process I see lots of different methods that may be used.As I use it I pick different methods in each level depending on organisation, product or project. Sometimes not all steps are neccesary off course. When working methodically for some time you start getting a feel for what seems like a good ide or not.
In this post I’m presenting a framework of the process as well as the methods in short formats. I will try to post more in dept posts on some of the methods going forward. Please let me know what methods you would like to know more about 🙂 Hope you find it useful in your daily work.
Download the one pager for Product Process and Tools here >
Here is my blogpost on the product development process with a continuous discovery and delivery process with one team >
Note: Due to some lazyness there are some Swedish material in this article also – sorry for that!
1. Strategy
Why are we doing this? What is the goal & desired impact?
1.1 Concept
Concepts enables people passionate about a product idea, regardless of role, to realise it all the way to happy client. Concepts is a one page specification, in A3 format that represents a product idea of feature. It is enough to enable a prepared conversation with engineers developing the product. Think of it as a “flexible minimum specification”. Mattias Skarins blog post on this http://www.crisp.se/concepts
Here you can download the Concept template I have created from Mattias Skarins examples >
1.2 Impact Mapping or “Effektstyrning”
Impact mapping can help you build products and deliver projects that make an impact, not just ship software. Impact mapping is a strategic planning technique that prevents organisations from getting lost while building products and delivering projects, by clearly communicating assumptions, helping teams align their activities with overall business objectives and make better roadmap decisions. Can be used on all levels, Roadmap/Project/Feature. http://impactmapping.org
Here are some examples of Impact Mapping as well as a one pager on how to from Gojco >
Here are some examples of “Effektkartor” and some slides on how to >
1.3 SWAT analysis
A SWOT analysis (alternatively SWOT matrix) is a structured planning method used to evaluate the strengths, weaknesses, opportunities, and threats involved in a project or in a business venture. A SWOT analysis can be carried out for a product, place, industry or person. http://en.wikipedia.org/wiki/SWOT_analysis
1.4 Star Gazer
Quickly maps up what weakness or strength there is in the product or idea. Could be used as framework for quick bench mark also.
2. Research
Who are our target users & how can we help them?
2.1 Agile Requirement Analysis
This is a quick and good way to collaboratively discover what end user needs there might be in the product. Involve people all over the organisation to quickly access Clients/Business/Tech/Partners needs and prioritise them. Dig deeper in needs only if needed. This is one of the 7 dimensions in Ellen Gottesteiners model “Discover to Deliver”. www.discovertodeliver.com
2.2 User Research
To discover real pain points as well to find what specific needs our users have, and what expectations they might have we have to meet our users. Its always best to visit them in their home or at work where they use your product. Second best is to meet them at your office. As you move away from the f2f encounter and their own space, the colder it gets.
– Usability testing (5-8 users/target gr.)
– User Interviews (min 10/target gr)
– Questionare
2.3 Product personas
Create personas based on user research for the product, usually 3-4 per product. A product personas represent a target group, or a part of a target group it should be based on user needs. The personas is used through out the project or longer for a product, it makes every one involved more emotional in touch with the user. Usually we can adress all features to a persona and therefore have more knowledge in how to design it to make it useful to our users.
2.4 Proto personas
A proto persona is a persona that is created quickly based on knowledge within the company. It is created as a collaboratively activity and can be seen as hypotheses. These hypothses can validated through out a project as a part of the iterative user centric process or with user interviews.
Here you find a template for proto personas >
2.5 Psychological Buying Personas
Bryan Eisenburgs 4 psychological personas can always be used for all products. They give us 4 different perspectives on how users make decisions and what they value in the buying process. I have also added a template for where to put information in a page to adapt it for these 4 personas based on how slow or fast they are.
Here you find my material on psychological personas (in Swedish) >
2.5 Experience Mapping
To discover user experience highs and lows and what opportunities there we have in the service/product. Could be used in a big scope for the total user experience, as well as zoomed in for a specific flow or feature. http://mappingexperiences.com
Here you find a guide to Experience Mapping by Adaptive Path >
2.6 Gamification Benchmark framework
Octalysis is a Gamification Framework that helps you benchmarking different services and give input on what could be done to use intrinsic motivation in order to change user behaviour for increased LTV, create more brand promoters and more. http://bit.ly/1myEVGd
Here you find two examples on Spotify and Netflix that I have borrowed from Anders Härén >
2.7 Conversion review – The L.I.F.T model
An expert review through conversion framework to find hypothesis for improvements all over the product or on one specific page or function. The framework helps us asking the right questions and understand what could be cousin problems. The airplane is from the conversion agency Wider Funnel.
3. Ideate
Expand and generate lots of ideas quickly
3.1 Hypothesis for solutions
Generate ideas based on hypotheses. “We believe – If we do this – the impact would be this”. Work in small X-funk groups and generate many hypotheses, sketch on ideas for solutions – test ideas quickly on each other, or real users.
My Crisp colleague Peter Antman just posted a blog post on this >
3.2 Design Studio
Quickly sketch on solutions in X-func teams, also invite CS or other who knows your user needs. Quickly create one or several LO-FI prototypes.
3.3 Benchmark features/look & feel
Just comparing what solutions other services have and what that might do for their users or business. Doing this as an activity in x-functional teams gives you shared knowledge – it´s fun! Might give ideas on what user expectations are be for your service. Possibilities to steal with pride or not make the same mistake perhaps?
4. Verify
Keep short feedback loops to verify assumptions and minimise risk
4.1 MTP – Minimum Testable Prototype
Create Minimum Testable LO-FI Prototype. Test user behaviour and flow – get feedback quickly to o create prototypes to test on real users is a great way to minimise risk.
4.2 Testing new ideas
There are several ways of quickly test if the product idea is interesting. Using Ad Words is a great way to see what users search for and act on gives instant input.
4.3 Qualitative user testing
Test on users to learn if users are able to complete specified tasks successfully and perhaps identify how long it takes. Test often with real users, 5-8 to uncover most flaws. Watch them use the product/prototype to gain knowledge on what could be fixed before starting coding or before release. Could be done by anyone in the team who knows the framework of testing, it is important to ask the user to speak out loud, and not to give instructions during the test. http://www.nngroup.com/articles/flexible-usability-testing/
4.4 Quantitative testing – A/B testing
Test your hypotheises for changes that can give you learnings on what works or not. Set a clear goal, analyse and test. A/B test one or several ideas. Multi Various Testing is for lots of different options where the software automatically set together the different alternatives, this is a bit mor tricky, since it is more difficult to get good learnings from the test. Split URL test for advanced changes on dynamic content.
Narrow down and prioritise solutions based on value
5.1 Kano Model
Prioritisation of features and content in service based on user expectation and motivation. Everything moves down in time from exciters to must haves. The kano model is divided in 3 levels: must have, should have and eexcites delighter’s.
5.2 User Story Mapping
Build the story of the product/feature from scenarios together in X-func teams to minimise handover and plan the project with deep discussions on solutions just from use stories. Cluster user stories from different scenarios in activities, slice in tasks and prioritise within activities. Used in large or small projects to align team and prioritise.
Jeff Pattons guide on how to >
A case study of how you can use User Story Mapping (in Swedish) >
5.3 Slicing for Value
This is something so many are failing to do – and it is of such a great importance! You want to slice your stories together with the team to prioritise and focus on building value. Your goal is to attain a set of high-value, ready stories that are about equal in size and are sufficiently analysed so that you can size, plan, and deliver them as promised. If you perhaps do a User Story Mapping, you should slice at the workshop, if not it´s time to get your team together for a backlog workshop 🙂
Elephant Carpaccio exercise by Henrik Kniberg and Allistair Cockburn >
Slicing guide by Ellen Gottesteiner >
5.4 Minimum Valuable Product
Keep in mind there are several ways of testing your idea and deliver value in the shape of feedback – or user / business value.
My colleague Martin Christensen created a great MVP Guide >
5.5 B.U.T values
This sounds a bit stupid perhaps, but it´s really great! I implemented this on Viaplay in all Jira tickets, as well as in the Concept we started using. What you do is that you push every one to always specifying value on everything that goes in the backlog. It hells team and PO prioritise more transparently.
Business value value 1-5, User value 1-5 and Tech value 1-5.
5 being critical – and 1 not important. Makes it easy to prioritise all items equally since all aspects are equally important.
5.6 High / Low matrix
Quickly and easily map ideas based on high/low impact/cost on your teams kanban board or right at the workshop. Discuss and evaluate together to learn from each other and improve as a team.
Read more on on this at the great game storming website >
5.7 Buy a feature
This is a game to play for prioritating from different perspectives. Either play it with real end users and different stake holders, or play the role of them. All players get a pot of money, the pot should be less than the cost of one features. The idea is to get players to discuss and try to convince each other in the group. One group could perhaps be business stake holders and another group real users from a prioritised user group. It helps team and PO prioritise on value.
You can read more about it here on the game storming website >
5.8 Prioritisation of features
This is a simple but effective tool where you give points to features from different perspectives to see what feature gets the most points. Good to use with stake holders to get a common view on prioritisation.
