It is very easy for software product owners to be lured into the trap of designing software to solve a broad problem for many people right from the start. This is a mistake. Most ideas start to scratch an itch or build something that is unique to a particular company or group. Then as you think more about solving it, the natural tendency is to go bigger and think “hey, this could also solve these similar problems!” You increase the scope of your project to encompass those problems as well. After all, it’s software, there’s no cost to make your product just a bit more generalized, right?
No. Again, this is a mistake.
Build to solve the smaller problem. Learn the domain by focusing on solving the problem you started off with from A to Z. Once you have done that, expand to similar problems or refactor your software to a higher level of abstraction.
For example, say you rent a house and find it tough to communicate with your landlord. You decide you want to build software to help landlords communicate with their tenants. Great. As you start thinking about it you realize that you could also solve the problem for people who rent out their houses to vacationers for the summer or for commercial apartment building landlords to communicate with many tenants in a building. After all, they’re basically the same problem, right?
No.
They require different models, different abstractions and different user interfaces. Solving everyone’s problem means solving no one’s problem. Instead it means getting bogged down in creating software generic enough to not exclude any potential customers. It may seem like you’re making big fancy plans and building elegant software models when in reality you are severely lengthening your time to market and setting yourself up to build a product that doesn’t fully solve any one of your potential customer’s problems.
Here’s what not to do:
- Don’t try to solve a problem that can be described in two words like “Project Management” or “Travel Guides” or “Technical Training” or “Note Taking.” Your first product should be much more specific. “Note taking for software developers,” for example.
- Don’t start trying to sell something that has even the smallest geographic considerations to customers globally. Instead, pick a country or state and go from beginning to end with just that segment of the market.
An example in the software world is Ruby on Rails. It didn’t start as a broad framework. It started as a product–Basecamp. It wasn’t until after Basecamp was successfully built to completion (depth) that 37 Signals extracted Rails as a general framework that could be used to build other web applications (breadth). Contrast that with Meteor or Famo.us. These are frameworks built to solve huge problems for many people. They are promising but have been extremely expensive to build and growth has been quite slow, in fact for Famo.us, it seems to have stopped completely.
Resist the temptation to start by building for a broad market. Focus. Build a product that completely solves a small problem, then expand it.
One reply on “Breadth after Depth: Don’t Set Yourself Up to Fail in Software Projects”
I couldn’t agree with this more. In fact, after you went to Avalara, Nikki and spent months doing research on what should be built for Trakstar next. What surprised me the most was the large amount of formalized tools that can be used. We did business model canvases, market research with gartner reports and others, competitive research, how we wanted to differentiate, etc. After that, we had a very narrow focus on what we could build that would add value. Deciding what to do became easy. We left shortly after though.
So I echo exactly what you said, only for next time I’m going to put even more emphasis on the research phase understanding the customers and market. Which is exactly what UX researchers do. Incredibly valuable and can save years of your life building features that don’t have the impact you’d like.