Case Study

Challenge

In late 2022 a product team approached me with a need: “One of our customers wants a new feature, and we want to “hack” a part of our software to do it. We want you to validate our idea. There’s no time, we need to have the new feature live in a year, and it’s only one customer. Oh, and they have created an in-house solution for this but want something integrated into the bigger package. 

This story sounds familiar to anyone working on a software product team, especially in B2B. A customer wants something close to what we do, so we’ll give it to them. It may mean a specialized tweak for them, but the software is super-customizable, and we just need to get this done quickly to move on to bigger things. 

The shift from the problem identified to the solution lasted about 2.5 seconds. A classic idea-led solution scenario. Yes, there was a deeper examination of the “hack” solution. Still, the examination did not involve customer-facing research. And the argument against doing any customer-facing research is three-fold:

1. It takes too long – we need to start building soon if we are going to be fully tested and in production in time
2. We know our customers. We have deep relationships. We know what they need.
3. We can use our customer-service people as a proxy for external users. After all, they work without customers daily and know how to use the software.

Again, this should feel familiar to folks in the B2B space. Timelines are always tight, so we’re always looking to find velocity. It’s about a short-term win. Let’s satisfy this customer’s needs now. We know what they want. We know how we can do it with a quick bit of customization. There’s no need to dig any deeper.

At this point, my research spidey-sense was tingling. The analysis to this point was good, but it only skimmed the surface. The questions and description of the desired outcome were very shallow and did not leverage the power of the software or align with the company’s vision. In other words, it was a band-aid solution that, in the long haul, would have very little value for the company. In my head, I couldn’t see where the solution would take the company or, for that matter, the customer. It might solve a small problem today, but it had nothing for the longer term. Would this become a case of failing slowly and expensively?

As the project team was forming, I learned that they, too, were not sure about the “hack,” but for the concerns listed above about time and getting it done, they were willing to go ahead with what was planned.

With both the desire for speed and the cautionary tale of failing slowly in my head, I considered how might we both look at the hack solution and dive a little deeper to see if there was a better idea to be discovered. In my head, this was a bit of Yes…and: Yes, could we still gather requirements around the hack (or idea-led solution) …and could we dive into the problem space more deeply and see what comes out? 

I suggested a layered and concurrent approach running three research sub-projects that would each inform the other (layered) and doing them in a very tight window, overlapping the start of the second two with the first (concurrent) analysis. The aim was to collect insights to validate the idea on the table and explore the problem space. 

The research consisted of three separate but linked activities: 

1. We started with internal group white-boarding sessions with customer support and sales teams to understand what they hear about the feature in question and what the steps in the user journey are for that feature and allow them to identify what they would like to learn from our customers about it.
   
   This activity would support validating the idea on the table and opening up areas within the problem space to explore. 

2. At the same time, we started running cognitive walk-throughs with our customers using an early version of the hack. We also did a walkthrough with the client who’d built an in-house system.
   
   This activity primarily focused on validating the idea on the table and supported our analysis in the more exploratory parts of the research. It also opened the door to understanding what was working and, importantly, the workarounds people used.

3. Run online journey mapping workshops with groups of clients from the same region. 

   This activity was very exploratory, not only getting clients to describe their actions, thoughts and feelings through that journey, but also we had a roundtable on key questions where clients told us about their experiences and shared. 

I’d tried something similar the previous year with internal teams, which produced very good results, so the product manager was open to this approach. With the success of the last year’s work and knowing how the group sessions would run, he felt more confident saying yes to setting up group sessions with customers.