Picture it: We’re in a room with our colleagues, attempting to determine the relative importance of features for a product (because we can’t do everything) but it quickly turns into what I call a feature debate …
Ever been in a meeting like that?
It’s the kind of discussion where people try to justify the features they want. Sometimes it’s based on their opinion, sometimes on what they’ve heard through their own “research” (eg. asking friends and family or people in coffee shops), and sometimes it’s even based on a business goal.
Feature debates rarely end well—we feel like we ‘lose’ when a feature we want isn’t included in the team plan. We get upset, politics become aggravated, and it leads to conflict within our team. Not to mention that feature debates can be quite expensive to the business; after the meeting they often trigger a lot of back-and-forth communication that becomes a huge distraction from what we should be focussed on.
So, given such clear drawbacks, why do feature debates still happen?
I think they’re a clear sign we’re not doing enough research. If our team has done the groundwork, we can easily integrate these research findings into the feature debates. For example, we could counter an opinion by saying something like “Well, in the research we found that people had problems with _____ therefore we really should prioritize feature ____.”
Sure, it’s easy to argue research. But good research should back up every insight with evidence; the stronger the evidence, the harder it is for people to dispute the findings.
Here are three more signs that our teams may not be doing enough research:
- We see a poor conversion rate on sign ups or purchases
If our product is having slow adoption (or no adoption) it’s a sign that we didn’t do enough research to understand the problem we’re trying to solve. Research helps us get a laser-like focus on the problem so we can be clearer about the exact features needed. But also, research helps us adopt the language our potential customers use so we can then in-turn use that language in how we talk to them about the product.For example, let’s say we aren’t seeing many people sign up for a free trial from our homepage. The first thing we should do is refer back to our research (or go to research) to help shape what we say on our homepage about the goals our product can help people achieve and some of the obstacles it can help them overcome. - We notice constant scope creep
Has your team ever set out to build a feature, only to find that by the time it actually launches it’s become far more complicated than originally intended? Scope creep happens because we allow additional features and ideas to be added during the product development process. Don’t get me wrong; ideas are awesome, but not every idea has to happen now.Every single piece of functionality should be backed by research. We should be able to map everything back to your findings, for example “this new ‘work-ready’ filter in our home-exchange app helps solve the problem of business travellers needing reliable wifi and 24 hour check in”.So if our team is experiencing scope creep, we should try to get into the habit of forcing ourselves, and our team, to justify every feature based on what we learned together from the research. - We see lower than expected user engagement
Let’s say we have a finance product for small businesses and we imagined people would be coming back at least once a week. But in reality 90% of people people are signing up for a free 14 day trial, logging in once, and never coming back again. Why is this happening?Chances are we created a first experience for people that doesn’t create an “ah-ha” moment; it doesn’t solve an immediate problem for them. It doesn’t create an experience that takes them from where they are right now to where they want to be. Knowing our customers enables us to help them succeed; if we’d done good research, we might have understood the problem people have with their current reality and the obstacles that are keeping them from what the want to do. Armed with these two pieces of information, we could have focussed on building a solution to address just that.
Research isn’t optional. Research is an investment, and we must start treating it as such. Yes, it will cost us a bit of time and money, but the return is worthwhile because armed with research we increase our chances of building the right thing. Without research, we may end up building the wrong thing, requiring us to go back and do a lot of re-work—not just on our product, but also in educating our customers and potential customers about what our product was intended for.
My advice about doing research is simple: start small, but just start. Don’t let yourself or your team argue subjectively in another feature debate. Don’t launch another feature that’s more complicated than it needs to be. And don’t confuse your users with with a poor first experience that doesn’t solve an immediate problem for them.
