You’ve just joined a new team, you’re being assigned to launch a product which is nearly ready, and from the moment you set eyes on it, something doesn’t feel right. You don’t quite get its value, you don’t see how others might want to use it, it doesn’t feel right… but then you don’t know your users yet. So what do you know.
That feeling doesn’t go away the more you learn about the product. It’s your responsibility to manage the product, but what if it was your responsibility to kill it?
This is what happened to me last year, and here’s how it went.
I found an ally
Coincidentally a new UX designer started at the same time as me on the product. After some getting to know each other, we started to feel enough trust to speak candidly. In theory the product was ‘ready for launch’, yet we both couldn’t understand how this product was going to do well.
It was very complicated, didn’t look particularly modern, and while it did some things well, it was a NEW site that our users had to start going to. Considering it was meant as a daily productivity tool, we really were not confident.
However, we also didn’t want only our expert opinion to shape the course of the product, and wanted to seriously consider the possibility we could be wrong. We therefore tried to approach the process as objectively as possible.
Get evidence, all the evidence
While we felt that there were some big problems with the product, we also knew that the team had been working on it on and off for 2 years and the director had been selling it to stakeholders as an answer to some of our biggest problems. So we couldn’t just go and say ‘hey, we know we’re new, but we don’t think this is a very good idea’.
So we did the following to build a case.
A private beta
We promoted the product to some 100 odd users we randomly selected to represent different job families, seniority and locations. We intended to observe their behaviour over 2 months. We saw that most went onto the tool and checked it out. Yet, only 1 user returned.
We sent a reminder to see whether a second go at discovering the tool (or maybe a first for those who hadn’t visited) might trigger them to come back. But still nothing.
Apart from that one user who seemed to like it.
Design workshops
Through several co-design workshops we explored what users might possibly need from such a tool. Previous user research had only included interviews on work habits and testing of an initial prototype. We thought a co-creation workshop might help us learn more about the daily habits of our users. We pretended we were still at an early design stage and didn’t show them the live tool in order to get a fresh perspective.
What we found in the workshops were that the things the users pointed out to us, were so different according to what type of job you worked, what your local conditions were like and your personal preferences, it would have taken a complex and highly customisable tool to actually create significant usefulness for our users before they would start using this tool. And we certainly didn’t have the budget for that.
User interviews and tests with our beta users
We also conducted user interviews and tests with some of the private beta users to see what happened. There we learned that indeed the page didn’t meet a significant enough need and they already had their ways of getting around and checking notifications, that they didn’t need another thing to manage that.
Some of the verbatim quotes the user researcher highlighted were a brutal wake-up call.
Bringing people along
Ok, so now, we had a lot of data to confirm our intuition, we needed to make a decision on what’s next. The way we approached the above steps were crucial in bringing people along to get to that decision point. All of the data-gathering was done in full view and often with participation of the two crucial groups we needed to bring along with us – leadership and the product team.
The leadership team
We needed to get their buy-in to stop developing the product, as they are ultimately responsible for our team’s work. We knew the evidence will get us most of the way – as our leadership team is very open to our inputs and will listen to facts (not something one should take for granted I have learned).
However, we also needed to understand internal politics and the implications that a strategy change might have for the relationships we have with other departments. We also needed to understand the potential emotional attachment the leadership team had for the product, and their openness to change course and defend a new strategy.
All of this was important to know, so that we could manage the change for them. Through my weekly conversations, I started sharing my doubts, first subtly, then more candidly. I asked about implications, first asking in terms of hypotheticals, then talking options. I also explained our approach to gathering evidence, and what we were hoping to learn from each step. By preparing them in increments, there was never a big ‘tada’ moment in which I revealed how I knew all along that the product was a bad idea.
The team
The concerns we had regarding the team’s acceptance were different. We knew that they would go along with a decision that was validated by the leadership, but we felt it important to keep morale high, and not let this process demotivate them. After all, this had been 2 years in the making.
Especially as a newcomer it was important that others were on the same journey. We didn’t come with a new vision for the product immediately, we facilitated enough of the reflection so that the change felt gradual for everybody involved.
The feeling I wanted them to take away was pride in the fact that as a team we were able to take tough calls to do the right thing. To listen to evidence, and challenge ourselves to build what’s valuable.
The different team members, a junior PM, a developer, a UI designer, a content strategist discovered the data with us. They had access to our beta test dashboard, and we reviewed the data together and prepared the user research together. With the UX designer, we tried not to jump to any decisions too quickly and mainly discussed the facts, and we asked the team what their conclusions were.
When deciding what to do next, we put the team in front of 4 scenarios (including one to go ahead with the launch). We empowered them to help us shape our next steps, and in the end they all agreed to go back to the original problem we tried to address. We also showed the leadership team the conclusion the entire team had drawn from the evidence.
Reframing failure
We had a final meeting with the team to discuss how we all felt about the fact that we stopped the launch of the product. It was a bit like a group therapy session. This also marked the end of our work together, as the next stage (back to the drawing board), wasn’t going to be with the same exact team. By giving everybody one last chance at sharing how this process made them feel, it gave us all the necessary closure.
We also had a big discussion about failure, and the role it played in product development.
How we talk about failure is very representative of our organisation’s culture. The reason it was important to bring the team along in this decision is to ensure that we could talk about failure in a constructive manner. They needed to co-own the process and realisation.
Yes, we got it wrong, yes we had good intentions but we lost ourselves on the way there. Then we all used evidence to stop the launch just in time to avoid investing in a product that was truly going to be a waste of money.
We insisted on celebrating that as a team we stopped a thing that was going to be a much bigger problem. Instead of feeling like we failed as a team to launch this product, we felt proud to have done the right thing and prevented a much bigger failure.
Sometimes you’re not the newcomer
In this process I had an advantage from the start, as I was new to the team. It can definitely happen that you’ve been part of a thing and it suddenly hits you that maybe it isn’t a great idea. Yes in theory we should be reducing risk and learning as much as we can as we go along, but in practice things can get out of hand before you know it. That could be because of stakeholder pressure, the difficulty of getting data, working in a reduced team, or just not being that experienced in product management.
So what do you do when you start doubting your product?
I believe you can follow similar lines to what we did, just the thing that’s missing is the ‘newcomer’ effect. As a newcomer people expect you to bring a new perspective. As an established team member how can you suddenly defend a new perspective – especially if you had previously defended this product?
I think it’s important to start sharing your thoughts with people you trust most, see what they think. Phrase them as doubts, not a complete loss of confidence in the project. Establish what you need to know to eliminate those doubts.
In addition, use the language of risk. Explain that you’ve identified this new risk – like the project might flop if we’re not completely sure we’re solving ‘x’ problem. Say how you want to mitigate that risk, and then start the process described above. Start working with your team on this, as soon as you can.
When one realises something that feels truthful, it can suddenly appear obvious, yet it doesn’t mean that it was easy to realise it without someone pointing it out or something triggering that realisation. (Most times when I realise something about the bigger picture of my product, I get the immediate feeling of ‘I should have realised this ‘x’ months ago’.) So, be kind to yourself and act with what you know now. It’s never too late to make the right decision and to change course in order to achieve user value. And even if it might be a tough thing to do now, in the long term the focus on user value will always be the right one.
Digital Good 