Start here

Every website you've ever visited, every app you've used on your phone, every video game you've played, every podcast you've listened to, every piece of software on your laptop; every single one of them is a product.

Mostly products are a force for good, they advance humanity.

But thousands of products with real promise are created every day, destined to fail, because the people creating them miss out some critical, yet straightforward steps.

This book will guide you through each stage of creating your product, using a method which does everything to make sure you're successful, in the fastest, most efficient way possible.

What's the method?

I've seen the best marketers sell millions before they even have a product. I've also seen game-changing products consistently emerge from easy-to-adopt scientific principles, experimenting and perseverance. So we'll combine both.

Build a community first, become an expert in their problem before you solve it, and sell your product before you build it.

Put another way, I’d rather a queue of people waiting for my lemonade stand to open, than opening my stand and waiting for people to come.

This is my guide to product management, designed to help you create a successful product, and avoid failure.

Life is too short to waste time building things no-one wants.

These are actionable approaches that really work. They're not theoretical. I've used them to create mass-consumer products, as well as deeply technical and complex software. I wrote this book using these methods.

I've run a startup and consulted at blue chips, and there are lessons we need to learn from both.

Here's the long read.

Why

What makes a great product?

It has evangelistic customers, and thoroughly solves its users' problem.

It also makes a lot of money and spreads quickly by word-of-mouth.

Most of the time however, people have no way of knowing whether the product they’re creating will be great, often until months after its release.

It doesn’t make any sense.

Forget a crystal ball, I want to show you how to do everything in your power to make your product truly great, before the first line of code is even written.

How you'd approach it if your life depended on it.

Throughout my career I’ve made many painful mistakes, and pivotal counterintuitive discoveries whilst creating products. I’ve also spent hundreds of hours learning and testing content from many high-quality sources over the years. I was lucky enough to start my professional life testing innovative business propositions at the R&D team of AVIVA, helped develop features on the BBC News website which are used millions of times a day, and led my own disruptive data science startup, from concept to commercial, as well consulting on a number of diverse projects in-between.

I’ve put together the best lessons from my knowledge and experience, wins and losses, so that you can cut a straighter path to achieving your goals.

You might feel you're ready to jump in and start making something now, but there's a faster, more effective route to success.

These methods are not procrastination. They're not wasting time, or over-analysing. This guide will save you time and get you to your goals faster and smarter.

You can conquer this discovery phase in a couple of weeks, and save yourself months, or even years of unnecessary hardship.

I eat my own dog food; that is to say I use this guide to shape my work. My hope is it helps you make better products, because better products make the world a better place. Worthy of a strong cringe, but I believe it's true.

Being the beneficiary of so many free resources, from starting startups, product management, through to learning to code and many more subjects, I wanted to pay it forward and share what I've learned.

What

This is a guide on the entire product lifecycle; conceiving of, researching, testing, building, and selling a product.

I aim to cover all the topics you'll need some knowledge of to build a great product, but it's by no means an exhaustive source of information on the subject. Consider this a jumping off point, to orientate you in the direction of areas of study which you may want to master.

What you’ll find here is a hybrid approach based on the best principles of product and software development I've encountered, combined with hacks that startups use to win.

This content will constantly evolve, so if you have any suggestions or questions, feel free to send me a message and I'll do my best to answer here.

Who

Perhaps you're thinking of building a product in your startup, or had an idea for an app. Maybe you're a creative, about to make and sell something digital. You might already be a senior product manager in gigantic company, or just starting out in the field. It's possible you already work in tech, and now's your time to build something yourself. You may just be an interested party, working with product managers, or maybe even hiring them.

Whoever you are, welcome. Here’s my guide to building products, like your life depends on it.

I define three phases to product lifecycle; discovery, adoption and expansion.

01. Introduction

In vogue

Building a standout product or service is an inescapable prerequisite of success in any company.

Products and services are created by almost every legitimately profitable company, and always have been; so why are we talking more about ‘product’ now?

Today, product is a mode of thought; an approach, not just a noun. Product-led, or design-led, or science-led thinking is something which I define as an emphasis on first principles, data driven decisions, experimentation, focused rapid low-cost prototyping, iteration, and customer centricity. Startups in the last 20 years often built products this way.

However products can also be, and most often are, created in protracted, waterfall-sequenced, opinionated, poorly focused approaches. Culture is normally the driving force behind which of these two broad methods is used.

Startups are increasingly incepted by science-literate people, often from engineering backgrounds, and within ecosystems which encourage knowledge sharing and cooperation. Silicon Valley incubated and developed much of the thought-process around what’s thought of as modern software product practice in the early 90s, and the reason it’s now making its way into common business parlance is because of its success.

I’ve seen first-hand the approach of building solutions where the opinions of senior people in the organisation drive what’s delivered, not user research or data. Enormous gantt charts made everyone feel safe; the future had been tamed. A lack of measuring meant no-one would ever find out if it had worked. No time to reflect on what could be improved once the product was delivered, moving straight onto the next vanity project.

It doesn’t work.

Persistence, not predictions

It’s not just big businesses who fall foul; as an individual, well, I’m guilty too. When I first started experimenting entrepreneurially as a kid, selling things I’d make, or creating websites I thought would generate a tonne of cash, almost always the reason for failure was trusting my gut instead of talking to users, or running a series of small incremental experiments. At one point in my early life, I painted Warhammer miniatures to sell on eBay (yes, I am a nerd).

I sold two and decided a glittering business empire lay ahead, so I bought enough packaging and materials for the next 50 miniatures. Saved some money buying in bulk. How smart I was. Except I then almost immediately saw artists in Poland selling better-painted miniatures at half the price. I sensed doom and gave up in that moment.

In hindsight, I should have created an online community, to develop fans of my work, published content, taken commissions (i.e. pre-orders) and yes, bought packaging in small quantities. I should have built the brand and hired freelance painters as demand grew. But as you might guess, me, aged 14, didn’t quite have the wherewithal.

We tend to trust our gut-instinct, and have an innate desire to predict the future. These are evolutionary responses to our environment, which have led us here today. But our innate instincts didn’t evolve to tell us how to build the next WhatsApp.

We just don’t have what it takes to accurately predict what’s going to happen tomorrow, let alone in a month or six months. A problem is, however, when it comes to planning in a business setting, we think we do. I’m not referring to predictions like cashflow or demand forecasting based on years’ of data, but events which are truly novel; like inventing a solution to a problem.

We thrive on predictability. Knowing the Earth rotates giving us day / night cycles. Cooking food kills bacteria. There are many activities in life which are certain, where we can write a plan and follow it exactly, knowing what will happen. But these are activities which we've seen countless times. When innovating, the same plans don't work, so we need a new way to approach investigating these unknowns.

We need to accept that the state of the universe is chaos. It might not be chaos, if in fact we had the computing power, whilst understanding all the secrets of the universe, and calculating the trajectory of every particle from the Big Bang onwards. Quantum realm dependant. For now though, it’s slightly easier to assume we don’t know what we need to know, right now, to make a success of something as complex as a software product, let alone a *physical product.

_{* The distinction between soft and physical products is simply that in software, refining the product is far easier, being able to change, scrub and move code/assets around. A physical product requires physical prototypes (if they can’t be modelled by a computer), which is far more costly and time consuming.}

So how do we contend with chaos?

Embrace it.

See a day as a pane of glass, slightly tinted, like the windows of a limo. Stack up a week's worth of that glass, one pane in front of the other, and pretty soon, when you look through, the slight tint turns to darkness. Stack enough panes for a month and you can’t see anything.

My ineloquent analogy is trying to convey that as much as we might like to know what the future holds, we don’t. There are too many variables which we don't control. Instead we need to be adaptable; not only that but persistently adapt to the obstacles and positive signs we find in our journey. In other words, expect the unexpected, and follow the evidence.

There are numerous modes of thought which have been developed to help (predominantly) tech professionals thrive in unpredictable circumstances. This book covers the practical things you can do to actively take advantage of uncertainty whilst creating your product. However, if you’re interested to learn other methodologies which deal with chaos, I'd recommend researching Agile and The Lean Startup.

Agile is a set of approaches used to break down work into small, fast cycles (often a week or two weeks at a time), producing fully formed 'features' to be released. Rather than retreating to a bunker to complete work and only surfacing for feedback months later, Agile ensures a much, much more frequent cycle of solving problems, completing the work, testing and critically, frequently releasing solutions for feedback. Atlassian, a company who makes software for those practising Agile, has created a comprehensive guide here What is agile?

The Lean Startup is, as its name suggests, a way to operate startups in the most efficient mode possible. Authored by Eric Ries, the book focuses on evaluating your business model as quickly as possible, as well as validating your product and its features. It recognises that assumptions require testing, and provides a framework to achieve this quickly and cheaply, whilst only working on truly necessary tasks. You can find out more here theleanstartup.com.

Product-led thinking

By combining a number of disciplines and approaches, you can create a way of working that not only deals with chaos, but thrives in it. Broadly it relies on following the scientific method.

You create a hypothesis, like ‘people at university are self-centred enough to want their personal information on the internet for friends to see’. Then you test it, by creating a prototype, and finally you measure the results to see what the outcome was. If you failed to prove your core hypothesis, try another hypotheses, repeating until one works. When you prove your core hypothesis, move onto the next experiment (the next hypothesis), a new feature, and so on until you have 2.5bn users world-wide. Then you conclude that nearly everyone is self-centred.

By breaking your working approach into many experiments, you can start to lose the ego associated with having to pretend you can predict the future. Designing the experiments now becomes the key, ensuring you’re trying to remove bias from your results, getting rid of overwrought opinion, and only following where the evidence leads.

Product-led organisations place their customers or users at the heart of not just their balance sheet, but how they operate and innovate. Objective data is the gold being mined, and product teams the people working it into genuinely valuable commodities. Grandiose analogy, but evidenced by the tsunamis of money investors have been pumping into product-led startups.

Large organisations who also implement product-led thinking start seeing every system or solution in the product approach; and for good reason. Focusing teams on following the data, experimenting, loving discovery, being collaborative, ditching opinion, and fundamentally learning everything about their users, tends to lead to great results. Whether it’s a new concept being experimented with, or maintaining a third-party system, product-led thinking is following a track which proves time and again, that the scientific method is very reliable.

Problems, the root of all products

I believe every successful product solved a problem people cared about. A book solves the problem of boredom, the need for escapism, the itch for cognitive stimulation, the desire to learn. Instagram solves the problem of needing to belong, affirmation, seeking out a sexual mate, artistic stimulation. The list goes on.

Look around your home and you’ll see products which only exist because there was a problem they solved, that needed to be solved.

However, I think many people who’ve made products were probably not aware of the problems they were solving, or even thought about products as being solutions. Yet in every standout product, I see a user problem that needed solving.

Humanity could have saved a lot of time, effort, and resources if we’d ensured every product we made was solving a problem people cared about.

As you follow this guide to create your product, I’ll refer to user problems throughout with great reverence, because in terms of your success, they’ll mean life or death.

Product and/or service

What's the difference between a product and a service? I see the distinction this way: products are often tangible things (a pair of scissors) trying to avoid the need for support from the provider. Services are often intangible processes, requiring interaction with the provider (a haircut).

Throughout this guide, I refer to products. However, increasingly products require a level of service to be valuable. eBay couldn't sustain its business model without providing users of its main product (the website), the customer service required to deal with disputes, or spot fraud and so on.

In fact over time, products often evolve into full services; a collection of products supported by processes. A growing set of entities trying to support all aspects of the customer experience. Sometimes services can be provided by AI, like chatbot support, and sometimes it's humans who conduct the necessary processes. In my view, we should treat them as valuable as each other, and consider them to be very similar. In fact the process of researching and inventing them is much the same. The difference is in how they're rendered; products often are made before use, and services rely on having a structure in place to manage the customer experience.

If you need to create a service, then you can also use the same framework laid out here to create it.

Products are like startups

I’ve created products for other companies, I’ve created a startup, and I’ve created products for my startup. Why do I say products are like startups? Well, very often startups begin by investing almost all their time and energy into creating a product to sell or distribute. Why does it matter? If it's true, then we can learn lessons on building great products from people building startups. In my opinion, the great startups, who turn into scale-ups and beyond, retain and refine this scientific way of thinking to drive their success.

I personally applied a similar approach to product-led thinking, when solving problems in my business.

For example at one point I needed to cold-call to sell my product. So I spoke to customers first, established first principles (reducing your assumption down to the point where you can’t ask why any more - I’ll explain more later), created a prototype script and tried it several times.

Then I spoke to more customers, refined, tried again and so on, until by the end I had a potent script, supported by a marketing website and supporting video to play on the call. It worked. But not because I knew how at the start, but because I swallowed my ego (as much as possible), followed the evidence and kept trying, kept learning, kept adapting.

So as you read this guide, if you’re also by chance creating a startup, consider using these tips to help build your business.

First principles and why they matter

If you ask ‘how’ something came to be enough times, the answer you arrive at in the end is quite often ‘The Big Bang’, or ‘God’, depending on your predilections.

In other words, getting to the bottom of things.

Knowing how ‘something’ came to be, provides far, far more insight than if you just examine the ‘something’ by itself.

Let’s try to get clearer on this.

First principles in essence tries to reduce down assumptions to the point where there is only a single answer - the correct answer. I refer to the engineering use of the phrase, rather than the philosophical (for those of you nerdy enough to care, like me).

The reason this is important, is so that you can effectively deal with the task in hand, without trying to appease other factors which aren’t important.

Performing a rain dance to induce rainfall doesn’t work, because you’re appealing to a god, which you believe controls the weather. It may have seemed like the most appropriate course of action at the time, because humans didn’t understand weather systems enough to do anything practical about droughts. When you do understand a weather system to a much higher degree, you can send planes to perform hygroscopic cloud seeding, and then rain ensues. This doesn’t mean a rain-making god doesn’t exist, but it’s recognition of the observable factors which cause rainfall, and then the ability to exploit them.

My aim in this book is to help you build better products. For me personally this is because I want two main outcomes. The first is to share my applied knowledge as well as direct experience, in a discipline (product management) which doesn’t yet have a huge and accessible (free) library. If I achieve this, then people will hopefully make better products and improve the world we share. The second and lesser reason, is to improve my own chances of working on interesting projects, by continuing to spread awareness of my work.

These are my genuine reasons, which by appreciating and understanding, mean I can ensure my efforts are spent achieving them.

I try to treat every aspect of my life this way, because these better answers or reasons, mean I can focus on achieving the things I want to achieve.

The same is true of my process in developing a product. I’ll advocate certain methods and approaches, because underlying each stage is the desire to create a successful product, in the most efficient manner, and these modes have been shown to work.

For example, I require you to find and connect with your audience before you even begin problem solving, let alone building a product. This is because if you want to create a successful product, you need to make something people need, and the way to know what they want is to ask them lots of questions. A very effective way of doing that quickly, is by connecting with the people you’re trying to help as soon as you want to create a product, so that you can understand their problems.

There are so many essential threads to creating a great product, but so many more which are dead-ends and waste your time. Therefore as you continue on your product journey, each time you’re faced with a challenge, ask how this challenge came about, and keep asking questions until you get to the real cause. It’ll save you A LOT of time.

How to use this book

My aim is for this book to help you take action. I know from personal experience that having content laid out logically, in easy-to-follow steps, really helps. So for each chapter, you'll see these common features.

Why products win
I think there are commonalities we see in successful products, most of which are achieved in the discovery phase of product development. In the diagram below, I’ve shown the high-level aspects of winning products. As we navigate each chapter, I’ll highlight how they relate back to this concept, to help us understand the importance of the tasks ahead.

We'll cover each aspect in detail as we progress, so don't worry about trying to comprehend this concept now. In summary it helps us ensure there's a need for our product, and our product serves the need. Sounds simple, but it's overlooked so often, it's almost criminal.

Theory and practical
Because this book is designed to help people who've never created a product, as well as experts in the field, I've split each chapter into theory and practical tasks.

For those of you who are creating their first product, I'd advise reading the theory first and then doing the practical tasks. If you're already an expert, you may just want to look at the practical tasks to find new ideas and templates to use.

Objectives
At the beginning and end of every chapter, I'll summarise the purpose of completing the practical tasks within that chapter.

This should help focus your efforts on what you need to accomplish for each facet of product development.

Practice makes perfect
One last thought before we move on. Every section of this book is intended to be used throughout your product's life. User research is something we continually conduct. Problem solving is a day-to-day activity. I show how to approach the subject, but the content here is intended for continual use throughout your journey.

Let's begin!