April 22, 2014

The three rules of product definition

Mohan Balachandran
Mohan Balachandran

Datica Alumni — Former Co-Founder

How does one go about defining a product? What constitutes a product? Some musings on the topic and approaches that we like to take with some examples from other domains.

I’ve always been interested in how a product is defined. How does one go about defining a solution to meet a market need that may or may not be perceived by the market in general? In the enterprise context, you need to spend time with the appropriate business personnel to define what problem they expect the solution to solve. Contrast that with the stories of how the iPod would never have existed if anyone asked a user (consumer in this case) what it is they wanted from a portable music player. And perhaps, that delta is the nuance - enterprise vs. consumer?

What is a product? How does one go about defining requirements? I’ll try and lay out how we think about products at Datica and how requirements are defined / inferred. This post is not intended to be a process model or description of how product requirements should be defined, but perhaps how they could be identified and how they could be refined / developed.

1. Identify the problem

There are two approaches here. The first is what I like to call a “Holmes-ian” approach which is best summarized by this quote “From a drop of water a logician could infer the possibility of an Atlantic or a Niagara without having seen or heard of one or the other”. Well - that approach is out (for me at least).

The more successful approach has always been to start with something that you relate to. Some problem you faced. PG has written an excellent (well, all of his essays are excellent) essay on this and I quote - “The way to get startup ideas is not to try to think of startup ideas. It’s to look for problems, preferably problems you have yourself”. Why? Because, unless you’ve lived it and tried to solve it in various existing ways but didn’t like those hacks, and you can think of a better way, then perhaps a market does exist for that solution. This is the process that led to us to building Datica because we saw that compliance was a requirement in healthcare but the existing solutions were extremely painful / difficult / unwilling to work with us. Which leads me to the next step…

2. Live the problem

Articles are always written about how founders had epiphanies on bus rides but no one talks much about the sheer amount of time spent after the epiphany on converting that idea into something that is tangible. The question is what exactly do you start building? A file syncing app - great! Where do I start?

If you step back for a minute, you realize that every product goes through two steps before it becomes reality - the only difference is how those steps are performed:

  • A. Research: The best way to research a problem is to live it. If you think that a frisbee could be improved, you live it for six years (if that’s what it takes). Or you decide that compliance needs to be simplified and you spend your waking hours reading through legislation and standards, evaluating current solutions, and talking to prospects.

  • B. Insight: Enough research / living it and you will have an epiphany. An interesting example of this I found was this where the designer completely rethought what a take out bag should be. Hint: no bag. In our case, the insight was commonality. HIPAA is HIPAA no matter who the user is. Seems simple but translating that into a product takes some doing.

Which leads us to the third rule…

3. Design / prototype / iterate on the solution - fast

The process of building something small and minimal, then iterating on it is a really good one. Start with a single OS, a single stack - get something working. Dogfood it. But spend the time on design. If you’re building a solution targeted at developers, design what the interaction could look like i.e. the API, even before the API is built. At Datica we use Apiary for API definition and it’s fantastic. This makes a world of difference - transforming a product from an MVP to an EVP.

I am a big proponent of designing up front. It does seem like there is no progress at times in terms of lines of code but I have learnt through long experience that the time spent upfront on design / requirements and documentation is well worth it. And this quote best sums it up - “You rush through design so that in the end, you have time to correct the mistakes you made because you rushed through design”. I don’t know who said it - it was passed on to me by a friend. It has stayed with me since then.

So, what’s the tl;dr version of this?

1. If you think a problem is worth solving, immerse yourself in it.

2. Immerse yourself in it long enough, that you understand what users really need.

3. Design / prototype up front.

Now all you need to do is sell it - which is an entire art to itself and perhaps the topic of another post.

tag Company