People are at the heart of Agile, design thinking and lean practices, so it’s surprising that users are often left out of product development altogether and when users are included it is often at the wrong times – their involvement reduced to nothing more than a token effort.
In this post, I’m going to explore the product development lifecycle and when you should and shouldn’t involve your users in order to create the best possible outcomes. I won’t go into detail on specific techniques but happy to explore these at different times.
To appreciate why teams make mistakes it is important to understand the boundaries that you and users share. Users are great at highlighting the problems that they face, they are great at testing solutions you put in front of them but are famously bad at coming up with solutions to a problem. Let’s face it why should they? That’s not their job it’s your job – you and your team have the skills, experience and knowledge to do it.
A great analogy is the Simpsons episode, ‘Homer Designs a Car’ – Homer is designated the average American, therefore whatever he designs will suit all Americans. The outcome is a shambles as you would expect, with a massive car fully equipped with 3 horns, muzzle for quarrelling kids and a massive price tag. The point being, users need to be part of the process but not running the process. The skill of product teams is to look deeper into the underlying issues and working with a cross-functional team to come up with amazing solutions.
We Have a Problem…Awesome
The start of any project is when you have discovered a pain point, a problem that you believe can be solved through your amazing software. Nothing gets a Product Manager happier than a well-defined problem, especially if you think this isn’t being addressed in the marketplace. Some of the best ideas, however, turn into the worst products, so your first test is to see if your problem truly is a problem. Regardless of how this idea was conceived be it stakeholder, user research, internal feature request and so on, it needs to be tested with your users.
It’s important to remember that the actual building of the software is usually the most expensive part of your process. If your new product/feature fails then it’s likely you haven’t tested with users during the early part of the product development lifecycle. You should be doing as much as possible to de-risk any product development. Being able to qualify new ideas (in or out) at a very early stage is paramount to success.
Note: I’ve moved away from the term validation and think more about testing, perhaps just a semantic point, to me validation feels like we have already agreed to something and we are just checking the box to say it is ok. Testing means we have an idea and we are going to see what people think and most importantly we are prepared to learn from that.
Now we have a well-qualified problem it is tempting to jump straight into a Product Design Workshop. However, before we even schedule a workshop, we need to establish customer needs, this utilises both qualitative and quantitative research.
The quantitative side typically has little direct user involvement and instead relies on analytics, market trends and surveys. Some established products have mechanisms to poll existing users which can be very powerful.
On the qualitative side however this will involve some in-depth user involvement, Great techniques include 1 to 1 interviews with experts and potential users. Many product teams like small group sessions although I’m not a fan of these, as you end up with groupthink, HIPPOS or dominant personalities stealing the show. These sessions are not about solutions more about better understanding the needs. What this does is to pick out the underlying issues, challenges and opportunities.
Example, you have identified that users want to take data out of your product. Through the research, you discover that users would be happy to export data from your product and put it into a spreadsheet. Involve users in your workshop and this is what you may end up with and it would be fine.
However, what are they doing with the data? Producing reports that they share with their leadership team as part of their monthly reporting. Therefore by understanding the type of information they produce for their leadership team we could build the reports within our product. This would a) save the user time as they wouldn’t need to do it in a spreadsheet themselves, b) increase the number of time users spends in our product looking at analytics, c) increase licences, if the leadership team can access this from our system themselves they can access up-to-date reports whenever they want and d) increase stickiness of our product by adding more value for the user.
“People don’t know what they want until you show it to them. That’s why I never rely on market research. Our task is to read things that are not yet on the page.”
This quote from Steve Jobs really capsulated it for me. You need to understand the underlying need (user research), come up with solutions (your team) and then test your assumptions back to the users.
Product Design Workshop
Stakeholders often assume that this is the time to get your users fully involved in the process, ‘if we are making a product for our customers surely we need them to be involved in the solution’
The most successful workshops I’ve had, the ones that have built the best products, haven’t involved users, not until the very very end when you are playing back your solution to them (testing). In my experience users fixate on their own use case and find it very difficult to think more broadly and to be fair why should they. They want the best product for themselves, whereas a product design workshop is about making the best solution for a wider breadth of users.
It’s worth reiterating the point here. During a Product Workshop, users are not actively present or involved in this ideation phase. Any solution conceived, however, MUST be tested back to users BEFORE you move onto development. This does not necessarily need to be during the workshop and most commonly isn’t. Remember, it‘s often not the first idea out of your Product Design Workshop that you end up taking through to Development. This is why user testing is so important at this stage.
We’ve identified a problem, came up with a solution and user tested. As we enter into the Development stage it’s important to continually get feedback so you can incrementally maximise the value your product offers your users. Hopefully, you are shipping your product in short iterations. This enables you to fulfil the build-measure-learn loop and will give you every chance of success. Build a bit, test the results, improve it for your users.
As your run through the development cycle you will likely have to compromise some features, let’s face it we never have time to build everything you will likely get to a point where you have to increase time, resource or reduce features. Again this should be a decision based on research, what is the core jobs of your product, what is the real value of your proposition? Asking users what the priority is and they will likely fixate on features that they want rather than the core jobs that need to be done.
The Product Owner is Not The User
During development, especially with Scrum Teams, you will have a Product Owner. Most commonly the Product Owner role is fulfilled by the Product Manager on the project. The Product Owner is a proxy for your user, the users representative on the team, able to answer questions during development around how the users would like to achieve a goal. This is based on in-depth knowledge of both the users and the product. The Product Owner should speak for your users when making decisions, however, they are NOT the user. A common mistake is Product Owners who haven’t had deep interaction with users and instead rely only on previous conversations, domain knowledge or just gut feeling, what they believe is best.
The only real way to judge the success of your initial idea is after you have shipped and measured against any objectives you had set at the beginning. Many great products and to be fair some not so great products get through all the above and then completely fail to gain traction in the market, ahem Segway, Nike Fuel Band and countless others. Having the right type of users, enough users and having them engage at the right times will help minimise risk and give the best chance of success. Once live you actually have the best volume of testing so don’t waste it, you may be surprised at which elements add the most value. Youtube, Slack and Groupon all started out as very different products, all were failing until they realised that just a small element of their product really held all the value to their users and they all pivoted around this core job – look up their stories they are great reads.
Keeping your users close to you as you run through a development cycle is really important. Ensure though that you are engaging at the right times to launch a successful product. Users are great at identifying problems and testing solutions and providing feedback. You and your team should be absorbing all the feedback and looking at the core jobs that the users are trying to achieve and build solutions that meet these jobs.