Products and Features are a Means to an End

This is a stream of consciousness or meditation on how I think about product development.

As the title states, all of this boils down to the idea that products and features are merely a means for solving a specific problem.

Every good explanation starts with analogy, right?

An analogy

Let’s say our user’s problem is that they’re thirsty but they aren’t able to quench their own thirst.

The means for quenching their thirst might be to provide them with a drinking vessel.

The end is that they are quenched, or no longer thirsty.

In other words, the value that we need to provide is the quenching of the user’s thirst.

So one way to frame this is that the design-and-build of the vessel is a matter of circumstance (a means) for quenching thirst. It’s not the only means, but it’s suitable for our situation.

Taking the analogy further…

Before we go to the drawing board and design some really slick container, we should consider whether we can achieve insights without doing any work or inventing anything new.

Perhaps the “least amount of work to an insight” is to not create a vessel, but to teach the end user how to cup their hands into a bowl.

We can then observe how they handle the situation without us doing anything. This will give us a better understanding of what kind of vessel it is that they need – that’s great, because we can still learn how to solve the problem without having to do very much work at all.

The “work” we need to do, so far: create a tutorial for the user who can now self-remedy the problem with tools they already have (their two hands).

Maybe we find that cupping their hands into a bowl to quench their thirst creates more problems.

Maybe the user needs a bigger vessel, or a vessel with a lid for reasons we didn’t foresee, etc. (Now we’re getting somewhere!)

What’s amazing is that we didn’t design a single thing, and we have insights that inform how our proof of concept is going to validate the problem: how best to quench the thirst of a user.

Frame of mind

Why is it important to do the least amount of work possible?

Because we are smart (and deliberate) about how we use our most precious finite resource: time.

The better we use our time with the resources we have (money, people, tools, etc.), then the better we are evolving as a business that makes our customers more efficient.

Greater than the whole

This contrived example of “thirsty users” is a long winded way to say that our job isn’t “to build products and features for our customers”, our job is “to solve their problems”.

It’s a matter of a circumstance that we usually solve their problems in the form of products or features.

What’s not immediately obvious but important to acknowledge here is that solving these problems is truly a team effort.

Everyone on our team has their own strengths and weaknesses, so it’s important for us to be open with each other because then we can everage each other’s strengths and help level each other up as we collaborate.

That’s when the parts of a team become greater than the whole.

That’s when we achieve greatness.

How do we frame our goals?

Let’s take a step back…

Maybe when we first started out we wanted to be the team that sells as many thirst-quenching vessels to as many thirsty customers for as cheaply as possible.

But in talking to users and experimenting with various solutions we find that there’s a very specific and very valuable subset of customers that will pay even more to have those needs met.

It’s not necessarily about either strategy being good or bad, but maybe we find that one is more profitable for us.

Alignment

Our team needs to understand where we want to be a month from now, a quarter from now, a year from now (vision) and why we’re doing what we’re doing (mission), so that we have a destination to chart towards, or an ideal to work backwards from.

Writing out these ideas helps inform us not only what to value but also how to prioritize what’s important in a way that’s not at the whim/opinion of any one person on the team.

The way in which we work together starts to become clear, and now we can start to understand what the process for working together should be.

We need the team going in the same direction and optimizing for the same set of contraints.

Measure, reflect, improve

It’s not impossible to improve something that you’re not measuring, but it can be hard to demonstrate (and feel confident about) because it’s not very rigorous.

There will be obvious improvements at times, but for other situations, how do you know you didn’t get lucky?

Metrics are not goals

Profits and losses are great indicators of successes or failures for a business unit but they are merely measurements that we use to better understand “how we’re doing”. It’s a proxy for the value we provide for our customers since the exchange of capital is quantitative.

The actual “value” we aim to bring to our customers could also be measured in terms of quenchedness, happiness, etc. just know that these metrics are harder to quantify and can be a bit more subjective than dollars and cents.

We will measure that qualitatively because they help enrich our understanding of a complex situation.

If your team is profit driven (their main goal is measured by profit) then it’s very possible you may make decisions in the interest of profit at the expense of the user’s actual needs.

Keeping in mind that profits are metrics and distinctly different from your goals is how Goodhart’s Law works:

When a measure (metric) becomes a target (goal), it ceases to be a good measure.

Humanity violates this Law constantly without realizing it, so the least you can do is talk to your team and make sure you all can distinguish between metrics and goals in a productive way.

Working with agility

There isn’t one way to measure a team’s progress or productivity.

This section will sound loaded no matter how hard I try to abstract what I think is valuable about a team’s process, so we ask that you please bear with us.

I prefer to frame this idea as a team “working with agility” to a team “having an Agile process”.

You can hear a lucid explanation of what this means from one of the founding fathers¹ of the Agile Manifesto because he explains how the philosophy was repurposed over the years by people who (more or less) packaged it into something marketable that companies could buy. The act of that has somehow warped the original intentions, which are astoundingly simple:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.²

I will explain what to do with all of this in a separate blog post. But just know that it’s all a logical extension of the princples and values expressed above.