Looking to optimize your development pipeline? Having as much information as possible before you start developing could save you an entire iteration.

Whether it’s product development, sales, or marketing, a bit of research will go a long way to ensuring project success.

I grew up doing woodworking and carpentry projects with my dad. He constantly reminded me…

The same carries over to feature and software development.

Ask questions, gather data, convert that data to information, and act accordingly.

I’ve never found a case where a project/software platform needed the entire kitchen sink. The key is to weed out what’s ancillary and focus on the core mission of the project/software.

Here are a couple examples based on the type of request:

• The one-off “squeaky wheels” requests

  • “Bob wants to make all the text in caps and have it automatically convert it to lowercase so he doesn’t have to turn off CAPS LOCK”
  • To address this, do a bit of digging into why Bob can’t turn off his CAPS LOCK. If this is an internal development project, there might be a workflow or usability issue to address rather than a custom programming issue.

• The “must have because {competitor X} has it” requests

  • “ACME Widgets can glow blue when a user logs in! We need that! Now!”
  • Rarely does feature matching with your entire vertical market work. In this case, did into how said feature works with the competition’s product and, if possible, find out how users are using it. Then develop the next best thing.

What kinds of requests do you deal with and what kinds of data do you collect to qualify the request?

EXCERPT:

[…] The point is that a very small amount of research could have confirmed whether or not this was a good idea. As it was, the team was spending 20 or 30 hours building this screen….a significant amount of developer time! And for startups it’s an even more critical amount of time…because it is potentially taking away from some other growth activity.

Not only that, but there are other costs. The time to maintain the screen going forward is not trivial. And any associated support time as well. But the biggest cost is probably the most hidden, and that is the cost of additional overhead in the product for the people who use it.

Every feature adds complexity to your product. Even if you hide the new feature on its own tab it is taking up valuable space, not only in the UI but in your user’s heads. You’ve added another option that they now have to decide between. For the first feature added…not a huge effect. Over time, however, enormous. Every subsequent feature adds more and more friction.

It’s not scientific at all but I’m now thinking that:

1 hour of research ~= 10 hours of development time.

Or, in longer terms if more people appreciated how one day of user research can save weeks of coding I think they would do it more. It is remarkable what you decide to not build after talking to a few people closely. And it is remarkable how much you can learn from just asking a few questions or showing a mockup to a couple users.