How to approach data science in your business Learn more

We pride ourselves here at Made by Many towers on making great products without the fluff.

Sound bite laden innovation theory isn't what we're selling - time is better spent making than pontificating about how to make.

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:

Figure out what the problem is

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.

Do some research

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".

Take an educated guess

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.

Ask people what they think of your solution

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.

Finally, above all, always ask "why?"

'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.

Continue reading

Continuous Integration for iOS Development

When developing iOS apps a number of things are required for producing a quality product. These include the ability to run unit tests on the code and to t...

Julian James   ·   29 October 2013

A week in New York; what I've learnt so far

I've been here in New York for a week now, working out of our New York office that we announced last month. I'm very new to this city, so I thought I'd sh...

Chris Bell   ·   16 October 2013

London Betaball toy testers wanted!

Here at Made by Many we have been working on a project called BetaBall. We're really excited about how it has been coming together and we are at a stage w...

Ben King   ·   15 October 2013