Is this question so obvious and fundamental that is taken for granted?
Through the years both as a coach, and in other roles, I have met a lot of software development teams, and organizations, that face a variety of challenges. These challenges may be related to the product, ways of working, the tech, or the team.
Perhaps unsurprisingly the experienced challenges are rarely unique to a specific team. Has anyone ever discussed; the purpose, dependencies, legacy code, or silos? I am sure you have several other examples yourself.
After being part of “fixing” these challenges and situations in various ways, but rarely getting a sustainable solution in place, e.g. one that lives on after a change in personnel, I started to wonder if we were treating the “symptoms instead of the disease”.
So I took a step back and tried to see if the root cause of the problem was somewhere else. Working with the teams, we found that very often the problem seemed to start much earlier in the product development cycle, usually in the strategy or discovery work.
Basic Product Strategy
The discussions in some of the teams got me thinking;
- Are the teams aware of the “basics” needed to develop their product by them selfs?
- Or are they still just trying to deliver what they are told by someone else (like in the good old days), and don’t connect the strategy to the delivery?
Therefore I went back to the start of the strategy work with the most basic and important of questions – “Who is your team’s customer?”
Ohh, the amount of hesitation, confusion, hopelessness, and sometimes even shame I get from the respondents, as a result of this question. Everyone should know the answer to this one right?
This is why, going back to my statement in the beginning – I hypothesize that this question is so obvious and fundamental that it, in many cases, is taken for granted. It is just not talked about in any structured way, everyone interprets it by themselves.
What’s more intriguing is that, more often than not, you will get different answers from different team members and still others from members of the organization. And while I have no data on this, except for my experience, the discrepancy in answers seems to be more common, the bigger the organization. The more enabler teams, platform teams, outsourcing, contractors, and so on, the fuzzier it gets.
Take a moment and ask yourself the same question. Who is your team’s customer? Done?
Ok, below are some examples of the recurring answers to the question.
Do any of them sound familiar?
The business side of the company
I have no idea!
You should ask someone in CX/marketing about that…
Our internal stakeholders
The other development teams
The ones that buy our products
Why are we talking about this? We need help with how prioritizing our backlog… We don’t have time to go back to talking about that, we did that 3 years ago…
While some answers might be more correct than others (in a general sense), that is not really important, knowing in what sense they are customers and why is. You can have different types of customers. Knowing how they relate, and which to prioritize is absolutely foundational.
Definition of “the customer”?
Let’s start by looking at what the dictionary says;
Customers: one that purchases a commodity or service = The actor that generates revenue
But defining your customer as the purchaser is limiting
Instead, consider this;
Customers are not buying (purchasing) your product – They are hiring your product to get a job done
There is a famous quote from Harvard Business School marketing professor Theodore Levitt, which I am sure that many of you have heard before:
People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!Professor Theodore Levitt, Harvard Business School
Enter Jobs Theory
This is also where Jobs Theory was born, if we can define a customer’s “Job to be done”, it will help us focus on the customers and market that seek to satisfy that job (i.e. we solve the right problem).
We can define a “Jobs to be done” (JTBD) as = A goal that the customer is trying to achieve – independent of (your)solution
…and hence the Customer as = Someone, with a job, trying to achieve a specific goal.
While they can be the same person, this is not necessarily the same person as the “one that purchases a commodity or service”.
Examples of customers and Jobs to be done
Let’s look at a recent example where many of us had a “job to be done” that was like this:
- JTBD: “Stay healthy and avoid spreading disease”
- Need: Determine if I am positive for covid.
Now let’s imagine that CompanyOne has a solution for that Need: covid-tests. They start producing them and do great business by selling them to the government. With the help of healthcare personnel, the government then starts to distribute these to our customers with the JTBD.
So CompanyOne has three “categories” of customers, the purchasers that buy our product, the executors that facilitate the job to be done, and the beneficiary who benefits from the successful completion of the job. In this case, the beneficiary has no influence over the purchase decision.
|The person who feels sick||Nurse or healthcare personnel||The government|
Then along comes their competitor, CompanyTwo, who has developed a way for the sick person to take the test by them selfs, thus offering a solution requiring less effort and eliminating the need for the healthcare personnel. They could also sell directly to pharmacies and by doing so potentially reach a bigger market directly.
|The person who feels sick||The person who feels sick||Pharmacies|
As you could imagine this dealt quite a blow to CompanyOne’s business model.
This means that Our main Customer is always the beneficiary because markets evolve to remove executors (and the purchaser might change).
So, the solution will change but your customer’s JTBD will NOT change
(After this the solution was the vaccines, I wonder what next one will be?)
Another example of how the solution changes
Many people around the world seek to accomplish the JTBD of “Creating a mood with music on-demand” daily, whether it be on the commute to work or on your daily walk.
For those of you that remember, the Walkman pioneered the solution of this JTBD with the help of cassette tapes that you bought in a physical store. Since then a lot has happened, both in the way, we access the music and the platform for listening to it. Check out the image below for some highlights (and low points) for solving the JTBD.
In short, the technical & practical solutions and ways to access it have changed but the JTBD has not.
Instead, the availability, speed, cost, and amount of music we can access at any given moment have been optimized throughout the years. And will likely continue to be optimized.
So if you are looking at the market you have to target to stay relevant it equals the JTBD.
|Developing a phone app for distributing music||Creating hardware to play the music||Create a mood with music on demand|
|In-stable market||In-stable market||Stable market|
The customer’s JTBD will NOT change, it is therefore a stable market in which we must evolve and markets exist because of job beneficiaries!
Ask yourself the same question again – Who is your team’s customer? But this time, categorize them into beneficiaries, executors, and purchasers? Was the result different?
A quick intermediate stitch about figuring out your JTBD
Once you have defined your customer(s), defining the JTBD is the natural next step. You need to deep dive into research if you haven’t done it before. And there are many aspects to consider apart from who your Job Beneficiary is.
The JTBD consists of different steps and customer needs. For each need in every step, you can measure if your solution, can do it faster and with better accuracy than your competitor (or your existing solution).
“The ultimate solution can be envisioned once the job is known”For more information about how to do this, stay tuned or head over to THRV which has great tutorials about how to incorporate JBTD in your strategy work.
Let’s recap – Why is this question so important?
Again it may seem obvious – How do this question relate to all the problems above?
Well, the answer lays the foundation for telling the story of the purpose of your team, customer, and product, how to build it and how to collaborate.
- Without knowing for whom you are solving a problem and what job they are trying to do, you can never figure out how to solve that problem in the best way and hence never be able to prioritize – is it valuable?.
- How do you, choose a platform and build an architecture without knowing what is the foundation of the job, what will endure, and what is expendable – is it feasable?
- Can the customers use our solution to get the job done – is it usable?
- Business model – do the beneficiaries experience value for money/effort – is it viable?
- Innovation and “prediction” of the future – what’s next in the evolution of solutions to the job?
- If you think about it, it will certainly affect your; Product-market fit, product definition, segmentation, branding, marketing, etc, and so on…
Have the discussion
As concluded – knowing who your customer is and what their JTBD is – is fundamental for all other discussions regarding your product and team, whether it be strategy, discovery, or delivery. As a member of a team, you have a responsibility to make sure that everyone is aligned around this basic question and not just assume that everyone knows or has the same view as you.
So I would encourage you to have the discussion in your team surrounding who your beneficiaries, executors, and the purchaser is, and then move on to what JTBD you are catering for.
If you are aligned both in the team and in the organization, you have a foundation to stand upon when it comes to solving problems in your everyday work.
Side note: Many “product people” would argue that this is the role of a vision or mission, but in reality that comes later. It all starts with the question: “Who is your customer?”