Successful Product Development, part 1: Defining Success

You’re about to read the first part of a series of blog posts on the most common reasons why software projects fail. Unfortunately, it’s much more difficult to run a successful projects than one might think. Supposedly, 68% of them fail (according to some reports). While I don’t have much confidence in the exact numbers here, I wholeheartedly agree it’s a big problem. So, the aim of this series is to protect you from the most common pitfalls.

Definition

Obviously, my analytical mind won’t let me to approach this subject without a clear definition of what a successful project is, so here it goes: the product does what its users need it to do.

Sounds simple? Surely, but beware as there are nuances here. I’ll use my superpowers of a grammar geek to make an in-depth analysis of this definition to bring them to light!

Obviously, the product needs to work

One way of looking at this definition is to focus on the fact that your code works: the product does what its users need it to do.

If we have a TODO list manager, it needs to save the data instead of instantly forgetting all about our important pending tasks. It is absolutely essential that whatever we’re trying to make the product do, it works. To make sure we got that part right, we can subject our product to some rigorous testing sessions under different usage conditions.

Make sure you understand who the users are

Now, let’s put the stress on a different part in our definition: the product does what its users need it to do.

Projects are managed usually either by a project manager, or a product owner, or sometimes by developers themselves, but none of them are the real end users. What they need to do is try to understand the needs of their users. This can be done by interviews, user testing, etc. Unfortunately, a lot of times it’s determined by guessing or “common sense” and those usually don’t go that well.

For example, imagine if I were to create an app that is supposed to help you keep track of your bowling scores, I’d be in a bit of a pickle. I’ve only been out bowling maybe five, or seven times in my life. That hardly constitutes any experience with the domain. So, the first thing to do would be to go bowling (yay, fun!) with a notepad to write down all of the ideas that come to my mind. But I’m still a long way from the real heavy users of the hipothetical app — the people who participate in bowling clubs, leagues, and just friendly neighbourhood competitions. I’d still have to go watch them do their thing, talk to them what problems they face, etc.

Lastly, make sure you solve a real need

Let’s move the stress mark even farther: the product does what its users need it to do.

Don’t worry, I won’t drop on you another “faster horse” quote from Henry Ford. Even without it we know there’s a big difference between what people want and what they actually need. Identifying what makes the real value of your application is key here. We shouldn’t try to create a product that does everything the user might think of. Instead, we should aim for a product that addresses one real need and does a really good job at it. Think of it like sculpting — you receive a stone block and the more you remove, the more beautiful it gets. Remember what kind of master a Jack of all trades is?

Summary

It’s important to keep those rules in your mind at every stage of product development. It’s easy to let them slip and fall into one of the traps placed along the path to a Great Product!

So, as we determined the general guidelines leading to a successful product, in the next parts of this series we’ll take a closer look at some of the bigger obstacles we’ll face on the way. Stay tuned!