Jobs & employment blog

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 needs
4. Define product functions
5. Define product success criteria
6. Define product foundation elements

In the following sections, we will define each of the above by asking a number of simple questions and then validating the answers to those questions, in order 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?

Let us 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. Let us 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, and 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 need, do you agree? Otherwise there is no point to 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 ‘jobs to be done’ by the product. 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.

So, for any statement on your list that is not a core purpose of the product, does not address a user need, does not alleviate a user struggle or does not do a job that needs to be done, should be moved to the bottom of the list.

We will come back to the ‘product purpose list‘ later a few more times, and our objective should be to reduce it down to maximum five statements that can be sewn together to create a well readable paragraph describing the purpose of the product.

2. Define the user base

Next, let us 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 maximum 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 or the benefits to the primary users would significantly reduce.

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, which 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.

In case of corporate products, more often than not, tertiary users are the folks who generate and consume management information (MI) which is then used by the management team to monitor the Key Performance Indicators (KPIs) on both operational effectiveness and product usage.

This analysis should give us a decent view of who our tertiary users could be, so let us list down 2-3 most important ones at this stage.

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 needs

Let us 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 a 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 the them. Look at the user wants, ask questions and try and work out the real user needs,

What do our users really need? For example the answer could be:

What I really need is to de-stress myself, need a break, a get away (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 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.

What do our users struggle with (in the context of our product)? 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 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 top five needs and put them on the top.

Don’t forget to consider secondary and tertiary users as well for our product to be successful and viable.

Now, it is time to go back to your product purpose and again validate that the purpose is aligned to your user needs. You may have also discovered new users or decided that some of the users that you identified earlier are no longer valid, as our product does not intend to fulfil their wants, needs or struggles!

Now at this point you are really challenging yourself as the maximum limit to the answers to any of these sets of questions is 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, and 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, and then validating 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 on all the things that the product should be able to do. Let us list them down, consolidate similar functions into same sentence and you are often looking at a wish list of 20-30 sentences (or may be more based on what I have experienced!).

Now let us 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 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 service?

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. Why do we want a function in our product that no one will use? Or, maybe we forgot to identify a user? Or, are we inventing a function or a user or a need or all? Maybe we are not really clear about the purpose of our product, so we need to go back to the beginning.

At this stage, we are aiming for not more than five  core functions of the product that 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 product function to make sure they are aligned to each other.

5. Define product success criteria

At this stage in the process, we should be feeling a little bit more comfortable that we understand what we are trying to build, why and for who.

Let us now look at how will we know if it works? Let us ask a question and then validate the answers that we come up with full honesty.

• What are the indicators of product success?

List down whatever comes to mind and not debate at this stage. How would we know that the product is successful? The answer lies 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 the 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 needs.

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

• Can you measure them?

Well, if we can’t measure them, they are of no use. 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 success indicators of this product.

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

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

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

If not, what is the point of measuring it? Let us 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, let us 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, and should ask the questions in this section again and re-validate.

Let us go back and validate the product purpose, product users, user needs and product functions again to see if these align with our success indicators.

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 service and 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.

Let us look at some fundamental questions about our product that are mostly ignored at the product concept or product definition stage and come as an afterthought.

Again, let us ask 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 the overall investment case, hence on the success of the product.

• How secure the product needs 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 worse or restricted user experience. If the product is less secure than it needs to be, it will lose the important user trust factor resulting in the flight of users at the slightest of security incident.

In very simple terms, if no user data is captured and held within the product, it does not need to be highly secure – e.g. a basic recipe website or products where users just consume the information rather than interact with the product.

If highly personal, financial or diversity data is captured and held within the product, it needs to be highly secure even at the expense of a reduced user experience. As 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 weekdays, or over the weekends or just during business hours.

Generally, the higher the availability requirement, the higher the investment in the infrastructure and design of the product and a higher portion of the investment will go meeting the availability requirements of the product.

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

The emphasis here is on ‘needs to be’. This is related to the audit-ability requirements of the product. If every action by the product or any of its users need to be fully audit-able due to regulatory or compliance regime, a higher portion of investment will go towards building and validating audit-ability of the product. Consequently, less portion of the investment will be available to fulfil the user needs.

Look out for cases where the consumer of the audit information is one of the secondary or tertiary user. If this is the case, the audit-ability 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 emphasis here is on the words ‘likely product reach’ and this is related to the scalability of the product. The more scalable a product, the more it will cost to build, and if the original design was not scalable, it will be extremely costly to scale a product. Hence obtaining clarity on this question at product definition stage will save a lot of pain later on.

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

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, it also affects the digital marketing strategy including preparing for search engine optimisation, domain names etc.

Once you have answered these questions, you have a good idea of the security, availability, audit-ability, 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.

To sum up – a product definition on one page

So, we now have a;

1. Product purpose,
2. We know who our users are,
3. We have a pretty 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.

Let us put these into a page using the template shown below (we can use MS Excel, Google Sheet 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.

Related Blogs

“We’re in a perfect position to help individuals access the right opportunities”

AUTHOR