That said, we don't work in a silo. Making stuff in constant dialog with the people we're making it for is key to what we do. Telling the story of why we're doing any particular thing at any particular point in time is also important.

This is usually where a certain amount of nomenclature begins to form. Common sense takes a back seat as we are forced to talk in the abstract. Process creeps in, bullshit proliferates.

In the product (i.e. websites and apps) business, this takes the form of terms such as Customer Development, Strategy, Service Design and Technology.

These terms can quite quickly become useless.

They suggest that, in some way, there exists discrete disciplines which should be combined in the correct quantities (or even worse, in the correct order) to make a product. That this formula will always work, and that every individual who practices them does so in the same way.

We know that this isn't true, so we attempt to mitigate the fact our terminology doesn't reflect reality with even more terminology (ahem... "T-Shape") and endless debates about what it means to be an X, or do Y.

That's all very boring. So here's a plain-english, non-linear, guide to making the right product:

All products start off a little differently. For some, the purpose is an obvious, clearly defined problem for which your product will provide a solution.

For others, not so much.

Regardless, without a problem to solve, without a purpose, your product will fail.

Find your purpose.

We utilise dozens of techniques at Made by Many to conduct research, the details of each are irrelevant if you constantly remind yourself that you're doing it to understand the problem more fully.

Get to know those affected by it; talk to experts; find out why it's not been solved before; look for others who are tackling the problem; what attempts have been made in the past; how can you learn from them?

Put your ego aside: Your goal is to understand the problem and be able to articulate it to the rest of the team, not find an answer, gather insights or define a "vision".

It's time to let go of control and embrace uncertainty.

Bring something to life quickly, anything. Don't worry about it being the solution to your problem; it's just a guess, it's a common artefact to ground all future discussions in reality.

Once you have something in the hands of users, be lead by experiment.

Experiments are at the heart of any product design process. Whatever the scale, be it an entire code prototype, an A/B test or a sketch, the purpose is the same: start with a problem, propose a solution, bring it to life, ask people what they think, learn from and feed the results into your next set of experiments.

A product will emerge. There will be no eureka moment.

Now that you've made a thing which aims to help people in some way, allow those people to use it and see what they say.

Listen to their feedback, write down their ideas, and, in the context of the you understanding gained from researching the subject, work out why they suggested what they suggested. Their ideas hint at underlying issues with your solution. Don't take them at face value, work out what those issues are and change your solution accordingly.

Repeat.

'Why' is a fail proof bullshit killer. Always ask yourself, and others, why you're doing every activity along the way.

Why are you making that product? Why are you holding that workshop? Why are you making that prototype?

More specifically, what do you hope to gain from doing so?

If you don't have an answer, stop doing it, regardless of what worked last time, or what you believe to be best practice.