How to define a product in six simple steps

Learn how to define your product in six simple steps. Manoj Agarwal, Hays Director of Digital Services, shares the latest insights.

How to define a product: Key insights

Welcome to the first blog in this Practical Product Management series. The series will discuss a number of simple and practical solutions and tools to help through the challenging and evolving landscape of Product Management.

So, let us set an objective for this article. I want to be able to clearly define my product on one page. We will do this by following a simple set of six steps and asking six sets of questions.

The steps are:

1. Define the core purpose
2. Define the user base
3. Define the user’s needs
4. Define product functions
5. Define product success criteria
6. Define product foundation elements.

We will learn more about each step in the following sections.

How to define a product: Background

A strong product definition lets you communicate changes and create the right tool for the job. As with many things in business, communication is key, along with understanding your market and users.

In the following sections, we will define each of the above by asking a number of simple questions. Then, we will validate the answers to those questions to arrive at a clear and concise definition of our product.

1. Define the core purpose

Let us work out the purpose of our product by asking a set of simple but revealing questions.

What is the Core Purpose of the Product?

List down what comes to mind, there is little point in debating anything at this stage. If we are embarking on building a product, we must have a purpose in mind.

So, list about 10-15 bullet point statements that describe the purpose of the product. Call it the ‘Product Purpose List’.

From these, try and work out which statements represent the core purpose – the one thing that this product must do, and do really well. For example, your iPhone must be able to make a phone call. The Gmail app must be able to send and receive emails. The Spotify App must be able to play songs.

Now let us qualify and validate each of these statements one by one.

• What user need does it need to address? It must address a user’s needs. Otherwise, there is no point in this product. We will discuss user needs in detail later in this article.
• What user struggle does it need to alleviate? We all struggle with something or the other, what does the product do to alleviate one or more of its user’s struggles? In reality, needs come later – the struggles are here and now and produce needs.
• What job does it do that needs doing? For every user, there are‘ jobs to be done’. Some interesting, some not so. What does your product do to get that job done for the user? It’s an interesting concept – you can read more about it in the ‘jobs to be done’ section below.

Move any statement that fills the following criteria to the bottom of your list:

• Is not a core purpose of the product
• Does not address a user need
• Does not alleviate a user struggle
• Does not do a job that needs to be done.

We will come back to the ‘product purpose list‘ later a few more times. Your objective should be to reduce it to a maximum of five statements.

2. Define the user base

Next, work out who our users are by asking a set of simple but revealing questions:

Who are the primary users of the product?

These are the main beneficiaries of the product. In the case of consumer products, these are consumers whose needs the product is trying to fulfil. In the case of corporate products, these are operational staff who will use the product and are expected to benefit from it in terms of increased productivity, accuracy, compliance or simply better working conditions.

Make a list of primary users of the product. You are looking at a maximum of three. If you get more than that, the chances are you are segmenting your users too finely at this stage.

To simplify, think of it like this – you and I, as consumers, are the main beneficiary of Gmail and Spotify, so we are the primary users.

Who are the secondary users of the product?

These are the users that support the main beneficiary of the product – I.e., someone curates the Spotify music list for you. There are always secondary users of a product, who, if did not do what they need to do, the main beneficiaries would not benefit from the product.

For example, if you use or manage the customer service functions of a consumer product or an admin function of a corporate product, you are the secondary user of that product. So, now list a couple of your most important secondary users.

Who are the tertiary users of the product?

This is often the most interesting and most ignored user base. It often comes into existence as an afterthought. Tertiary users of the product are the main beneficiaries of the by-products of the product.

A simple example in the case of consumer products is the data generated by the users of the product. This data is then consumed by other users (think marketing folks) to provide targeted advertising to consumers; showcase their wares at the right time to you on your screen.

These are the users who actually fund and make the product viable, specifically where the product is offered free of charge to the main beneficiaries.

Primary users will not fully benefit from the product without the needs of the secondary users being met. The product, even if it were to fully address the needs of the primary users, may not be viable unless the needs of the tertiary users are met. It is not easy, is it? This is why Product Management is such a fast-emerging discipline!

Now, it is time to go back to your product purpose and validate that the purpose is aligned with our primary, secondary and tertiary users.

3. Define the user’s needs

Work out what needs the product is trying to fulfil for the user, by asking a set of simple but revealing questions.

What are the key user wants?

Now, this might read like a grammatically incorrect question but, this is exactly what we need to know. What do our users want? For example, the answer could be:

I want to go on holiday.

Or

I want a car.

List down all the key wants of your users that come to your mind, we will validate these later. You are looking at perhaps 10-15 bullet point sentences.

What are the key user needs?

Needs are different from wants and often are hidden behind them. Look at the user’s wants, ask questions and try and work out the real user needs.

For example, the answer could be:

What I really need is to de-stress myself, need a break, a getaway (from what?)

Or

I need to go from A to B when I want without relying on a mode of public transport.

List down all the key needs of your users that come to your mind. Turn the wants into user needs and review to identify the top five needs and put them on the top, followed by the rest.

We should now be looking at about five to ten sentences representing the key user needs that the product will address.

What are the key user struggles?

Needs often (not always) arrive from struggles that the user faces in doing a job that needs doing and can be done better.

For example, the answer could be:

If only someone could … just sort something out for me… please (i.e. find a break for me or a way to de-stress myself without me getting more stressed about it).

Or

I struggle with the set schedule of public transport, and calling or finding a cab is sometimes a struggle.

List down all the key struggles of your users that come to your mind. Now validate your list of needs. Do these really reflect the user’s struggles? By analysing the user struggles you may discover new user needs. Some struggles and needs may need to be combined into one sentence as they may reflect similar things. Turn the user struggles into user needs and do another review to identify the top five needs. Put them on the top of the list.

Now, it is time to go back to your product purpose and again validate that the purpose is aligned with your user needs. Challenge yourself to keep this to just five sentences.

4. Define the product functions

Did you notice that we are talking about product functions after we have talked about the product purpose, its users and user needs? This is important. Often the biggest mistake we make is to start talking about what the product will do before working out the purpose and looking at users.

Let us work out what functions will be delivered by the product by asking a set of simple but revealing questions. Then, validate them by asking further questions.

What should the product be able to do?

This probably is the simplest question of all because we already have lots of bright ideas. List them down, and consolidate similar functions into the same sentence. You could well be looking at a wish list of 20-30 sentences.

Now be brutal about each of these bright ideas and validate them one by one by asking the following questions for each one in the list.

Is it really necessary?

Do you really and absolutely need this function? If you have any hesitations at all, let us move these points to the bottom of the list. If you can only have five functions in this product, find out those five and put them on the top.

Does it address a user’s need, want or struggle?

If it does not, either remove it from the list or move it to the bottom. Why do we need something in the product that serves no purpose for the people who will use the product?

Who will it serve?

This is the killer question. If we cannot answer this question for any of the product functions, it’s best to remove it from the list. Ask yourself the following questions:

• Why would we want a function in our product that no one will use?
• Have I forgotten to identify a user?
• Am I inventing a function or a user or a need?

At this stage, we are aiming for no more than five core functions of the product. These should fulfil specific user needs for identified primary, secondary and tertiary users.

This is the time we pause and review the whole output so far. The product purpose, the users, the user needs and the product function to make sure they are aligned with each other.

5. Define product success criteria

At this stage in the process, we should understand what we are trying to build, why and for whom. But how will we know if it works? Ask a question and then validate the answers that we come up.

What are the indicators of product success?

List down whatever comes to mind and do not debate at this stage. How would we know that the product is successful? Does the answer lie in working out how will we know if the needs of primary, secondary and tertiary users are being met successfully?

After all, a successful product is one which meets its user’s needs. Notice that we could not even answer this question (or answered incorrectly) if had not worked out the user’s needs.

We should arrive at a list of 10-15 success indicators. Qualify each of these by asking:

Can you measure them?

Well, if we can’t measure them, they are of no use. For any indicator that we cannot measure, let us move it to the bottom of the list.

Can you afford them?

For the success indicators that we think we can measure, how do we capture these them? Do we need to buy a tool or technology to measure them? Do we need to build additional features in the product? Or do we need a new product altogether to measure the success indicators of this product?

This could be quite costly. Is measuring these indicators economically viable? If it is not economically viable for us to measure a success indicator, move it to the bottom of the list.

Now let us look at the success indicators again from the top of the list to the bottom and ask the question:

Does this success indicator align with the product purpose and user needs?

If not, what is the point of measuring it? Move these to the bottom of the list. We should now have between three to five key success indicators at the top of the list that we can measure, afford to measure and align to the product purpose and user needs.

If we have less than three success indicators, we are missing something. If so, start again from the beginning – we may not be measuring enough, so will not know if our product is a success or not.

If we have more than five success indicators, we are measuring too many. Ask the questions in this section again and re-validate.

6. Define the product foundation requirements

At this stage, we now have a pretty good idea of the purpose of our product, the users it will serve, and the user needs it will fulfil. We have a validated list of functions that the product will deliver, and we also know how we will measure the success of the product.

Now, ask these five key questions to work out the required non-functional characteristics of our product. The answers to these have a potentially significant impact on the design, architecture, technology and overall investment case.

How secure does the product need to be?

The emphasis here is on ‘needs to be’. If the product is more secure than it needs to be, it will be more costly to build with a worse or restricted user experience.

If the product is less secure than it needs to be, it will lose the important user trust factor. If highly personal, financial or diverse data is captured and held within the product, it needs to be highly secure – even at the expense of a reduced user experience. The security of the product and the data held within it is of paramount importance.

When would your users generally need to use the product?

The emphasis here is on ‘needs to use’. This question is related to the availability of the product to users. Does it need to be available 24 hours a day every day, or only on weekdays, over the weekends or just during business hours?

How traceable do the product or user activities need to be?

The emphasis here is on ‘needs to be’. This is related to the auditability requirements of the product. If every action by the product or any of its users needs to be fully auditable due to regulation or compliance, a higher portion of the investment will go towards that.

Look out for cases where the consumer of the audit information is one of the secondary or tertiary users. If this is the case, the auditability should feature as part of the product purpose, user needs and success indicators.

What is the likely product reach? 10, 100, 1000 or millions of users?

The more scalable a product, the more it will cost to build. If the original design was not scalable, it will be extremely costly to scale a product. Getting clarity on this question at the product definition stage will save a lot of pain later on.

Which geographical area your users are likely to be based in?

Again, notice the words ‘likely to be’. This is about the anticipated geographical reach of the product. Even if we want to start local and then expand (which is wise), it is important to know the like reach.

The capability of global reach not only needs to be built into the design of the product, but it also affects the digital marketing strategy.

Once you have answered these questions, you have a good idea of the security, availability, scalability and geographic reach requirements of the product.

At this stage, it is wise to go back to the beginning and start with the product purpose and validate the output of every step to ensure everything still aligns.

How to define your product: Next steps for your business

So, we now have:

1. A product purpose
2. We know who our users are
3. We have a good idea of the user needs that the product will fulfil
4. We can articulate the core functions of the product
5. We can measure the success of the product and know what these success indicators are and
6. We understand the foundation non-functional requirements of the product.

Notice that the answers to each of the six steps are limited to a maximum of five lines/sentences.

Put these into a page using the template shown below (we can use MS Excel, Google Sheets or equivalent).

And…voila! We have the definition of our product that we can use to communicate with our team, our stakeholders, partners etc.

The product definition can also serve as a baseline to ensure we don’t build a product that no one will use (if we use this to validate the product features before prioritising them). This will be the subject of our next article in this series.