Collaborative user research – Learning from Erika Hall

I recently listened to a podcast where the mighty Jared Spool talked to Erika Hall about collaborative or team based research. Erika is co-founder of a design company called Mule Design and author of Just Enough Research. These are the main things I learned about collaborative user research from listening to Jared and Erika talking about this:

  1. “The value in research isn’t the answer” – Erika made a great point when she stressed that the value of user research isn’t in finding the right answers. Instead, she argued that user research is about creating a culture where it’s ok to constantly ask the same question. It’s about finding out what today’s answer is, and finding a way to feed the answers back into your product.
  2. User research isn’t a one person job – I particularly liked Erika’s point about user research not being a one-man job. As she explained, “No one person can do this. You can’t have the research specialist off in the corner finding this stuff out and then running back saying, “Hey everybody, I have a new answer.” I’ve learned how important it is for everyone on the team to be aware of the experience you’re looking to develop and get feedback on.
  3. Create a shared understanding – Collaborative user research is all about making sure that everyone in the team knows what the goal is, as well as having a shared understanding of our assumptions, constraints and requirements. Instead of arguing what the behaviour is that we’re designing for, the conversation centres around “Given that we all know the same things, then you use that as a basis to evaluate something.”

Main learning point: From listening to Jared Spool and Erika Hall, I learned that UX research can be so much more powerful if the whole team is involved or at least aware of it. UX research shouldn’t be treated as a one-off project or something that generates a big report that you can then shelve. Instead, the focus of UX research should be about constantly testing your assumptions and asking the same questions. This shouldn’t be the sole responsibility of a UX researcher; a shared understanding needs to be in place for the team to work towards the same goal.

Related links for further learning:


Coravin – great tech even if you’re not a wine drinker

I’m a teetotal and I don’t have the faintest clue about drinking wine. However, I was intrigued by a new technology called Coravin. The problem that Coravin intends to solve is that once you uncork a wine bottle, and unless you finish the bottle in one go, the quality of the wine is likely to deteriorate. The technology that Coravin uses keeps the cork in the bottle, where it’s been since the bottle was sealed. As a result, you will be able to “pour glasses whenever you like, and know that instead of oxidizing, the remaining wine will continue to age naturally.”



These are the main components of the Coravin technology, which I took from the Coravin website:

Screen Shot 2015-10-11 at 08.21.33


Main learning point: Last year, Coravin decided to temporarily stop the sales of their product, after receiving reports of 13 wine bottles breaking under pressure, even resulting in a two chipped teeth and a cut that needed stitches … Coravin dealt with this serious  issue by halting all sales, only resuming business as usual after it had sent a repair kit to all existing Corvin owners. I haven’t tested the technology myself, but I’m very excited about the idea behind Coravin as it provides a very innovative solution to a well-known and longstanding problem.


Related links for further learning:



No more features on product roadmaps – Have themes or goals instead!

You might have read my one of my previous blog posts about the so-called goal oriented roadmap. I  prefer goal-oriented roadmaps over their more traditional counterparts. My problem is that ‘classic’ roadmaps contain a mix of features and timings, but don’t provide any context whatsoever (I’ve included an example in Fig. 1 below). I typically don’t include features on a roadmap and focus on user or business problems instead. As such, the roadmap becomes a tool for ‘working backwards’ – enabling product teams to explore solutions for given problems or desired results.

I recently learnt from Jared Spool and Bruce McCarthy about adding “themes” to product roadmaps. McCarthy told Spool about the concept of adding themes, and Spool became an instant fan. Like me, McCarthy isn’t a fan of having features on a roadmap. Instead, he suggests adding “themes” to the roadmap and this is why:

  1. Open to ‘options’ –  McCarthy believes that by having specific features on a roadmap, you run the risk of sending a product team down a certain avenue (and closing off any potential side streets). For example, if you were to just put “data dashboard” on a roadmap, chances are you’ll end up with a data dashboard. However, what would happen if you were to put “provide our customers with data to make key decisions” or “no data access” on the roadmap instead? By focusing solely on solution you run the risk of falling victim to what Josh Wexler calls solution sickness. Solution sickness is all about fixating on a solution and ignore any alternative ways of solving a problem.
  2. Customer focus – Jared Spool makes a great point when he says “When companies talk about features, they are saying, “Look at us. Look at what we can do.” He goes on to explain that “When companies talk about the problems of customers, they are saying, “Look at what you’re dealing with. Look at how we want to help.” It’s very easy to get fixated on features and forget about the underlying problems you’re looking to solve.
  3. Helping trade-off decisions – One of the things I love about both the goal-oriented and ‘theme’ approach to roadmapping is that it forces you to consider ‘why’ you want to develop certain products or services. What problem are we looking to solve and why? Why do we feel this problem is worth solving? Why should we prioritise this problem over others? Both the goal oriented and the theme roadmap approaches help make customers and their problems the core of everything you do as a product person. When I use the goal oriented roadmap, I always take out the “feature” layer purely because I don’t want us to be pinned down to one solution.
  4. “Marketing the story of solutions” – Which do you think would be an easier story to sell to customers? Option 1: “You can now use this real-time data dashboard which you can access via your content management system, enabling you to filter the data and extract reports” or Option 2: “You can use our data to decide on whether now is good time to sell your house?” … Easy, isn’t it!? As Jared Spool points out, the ‘theme’ approach makes it much easier for marketing teams to tell a story about a product or service: “Here are the problems we set out to solve and here’s how we solved them.”
  5. A more cohesive design – Design is another area which is positively impacted by a shift in focus from solutions to problems. From experience, I know how much easier it is to prioritise against a problem that you’re looking to solve, instead of trying to cram in a lot of features which you think might have an impact. As Spool puts it: ” Without a commitment to specific solutions, the team has flexibility.” As a result, product teams stand a better chance of creating simpler, well designed products.

Main learning point: I really encourage all product managers – the ones who aren’t doing so already – to think much more in terms of user problems instead of focusing on features. Not only will this help you in focusing your product efforts, I believe it will also make you much more customer centric.


Fig. 1 – Example of a traditional roadmap – Taken from:



Fig. 2 – Goal oriented roadmap example – Taken from:


Related links for further learning: