3 Questions to define a software product

Imagine you are in charge of creating a clear specification for a new software product. On one side you have your customer - a a high energy, super smart non-techie who flies off in tangents in every discussion yet has the most amazing business idea that needs a web and mobile app. On your other side you have software developers who want a precise software definition that goes over the nitty gritty of what the software needs to do.

What do you do?

Let me go over how we do this with our 3 question approach. This is part 1 in my series on defining software.

Back to the your problem:

How to define a software product?

Every software product we see on the market started from an idea. The idea came from the need. The need presented itself when there is a lacking of carrying out tasks.

This is where the software product management - SPM shines. Understanding the “needs” is the primary goal for any product manager. We use software solutions every day without understanding the true value of it. Mostly because we have it already. There was a time we didn’t have the most basic solution known to mankind, Emails. We can’t imagine that time when it took up to months to send a message, or “mail”, to another person living in a distance.

Then someone asked the question “why?”, the first step to designing a great solution is born with a word. Questioning the limits and vulnerability of the existing solutions. Once it was determined that the existing mail communication is ineffective, the new idea is born.

Then they asked the question “what?”, which is the second most important step to designing any solution. Now knowing the issues with the existing solution, questioning what can be done to improve it will give them more ways to think to replace the existing solution, or system, of communication.

Once they figured out what needed to be done, they asked the question “how?” they can replace the system. The final question to designing any solution, looking for the answers on how to replace the system gave them the access to the tools those were need to create the new solution.

The “why” the “what” and the “how”, the three fundamental questions to defining any products, or solutions. Understanding this paradigm can help any product managers gain confidence for defining products. Product managers’ lives becomes very easy when they understand the answers for these questions. To define a product that you are building, you must go through these questions in step-by-step process.

Understanding the “Why?”

First, the “why” will help you to understand the actual need of the software you are trying to build, for your customers.

The key to understand a product that you are defining, designing and developing, is to understand the need for that product. Without a clear statement of the need if you jump in to the “how” based on some rough ideas on the “why”, it will often result in a product with that don’t address the stakeholders’ requests (no matter how good they look and function well). Most of the time product managers can assume what the customers/stakeholders are talking about when they mention their need but to master it you must start with diving in to details at the beginning of your conversation with them. Ask them why do they need this software/solution, why don’t their current system/process isn’t working, how do they want to their current system/process to function, etc. once you gather the initial needs of your customer, document them to understand their lacking. Investigate the system that they are currently using. Research the answers that you might think is valuable to them and easier for you to design.

The ”why” often usually helps to describe the vision of the product.

OK, the comic strip on the right is just a joke but a really good one, the why should always be aimed at the end user not company that’s profiting from the software!

Awesome “Why?” joke thanks to rstevens

Planning for the “What?”

The next step is to find out “what” can you do to provide a solution (or a product as a solution) for customers to overcome their difficulties. A very good practice is to investigate the process on the Internet and see how many have solved this need. It always helps to learn from your competitors. One bad practice is to jump to the development phase. In this way you may not know for sure, that the solution you have provided to your customers will serve them longer, or they can get any value out of using it, with the tools and technology you used to build the product for the customers. You must be able to plan more than one solution for a single need and try to understand the flaws in them. You can also use the help of UX and other interaction professionals to develop mockups or wireframes to show how concept of the product you need to build.

The “what’ part of the process helps you to capture the requirements, feature specification and milestones.

Deciding the “How”

Now that you know why and what you are doing, you can now jump to code. The third step gets easier when you have finalized what you will be building and why. Now comes the challenge on “how” to build what you have defined. With all the materials, such as business requirements, feature requirements, UX, models, your life becomes more easier to decide on the technology you will be using and design milestones in building the product you defined. This part is where you can race to code to build the product that your customers desire. Developers and architects should be given the freedom to make decisions regarding the implementation process.

In another way of saying, the “how” helps “what” is required to be built.

Concluding

To put a product on the (hypothetical) shelf, product managers have to be very precise in what they define as their product, both for the customers and the engineers. Using the “why”, “what” and “how” approach will help you to achieve that more efficiently and precisely.