Building a product from scratch

What’s your ideation process like and what are the key factors considered when building a test?

We work on a problem that a lot of our team had seen out in the world, working with real clients, real agencies, real users, all the time. So we had a lot of ideas already in-house. We then did some rapid prototyping to turn those ideas into different models. We flashed those models in front of real clients to see which ones they picked up on, and we used real client feedback to drive what we then went on to build.

We also found that the process would need to be quite flexible and future proof, and that’s why we built a technical foundation, which can achieve everything. So we had lots of different ideas, client feedback to help pick the ones that would work, but then make sure that everything was possible after that.

How do you currently test the product with your users?

All the time. In a world where people don’t want a faster horse, they really want a car, we show clients lots of different faster horses and then secretly bring along a few cars. We always ask clients, “What is your Holy Grail?” This tells us how to improve what we’re already doing and then also gives us a couple more ideas on what we can do next.

If clients seem to value and repeat the same thing many times, that’s what we start building. So, we provide flashing faster horses, build prototype cars and show them to people, and then we let clients tell us where to go next.

What are the key things to consider when building a product to make it scalable?

We really thought about this. When we first did ideation, we heard so many different things that we realised the product we had built would, in future, need to do a lot of different things. So we had a choice of two paths: (1) Where we would build MVPs and just get them in the market; (2) Where we would do that plus try to cover some technical debt and build ahead so that we could deliver all of these things in the future.

We took the second path. We built our tech so that everything could be possible, and we gradually added products on top. It slowed us down a bit, it probably cost us some money and some time, but I think it was the right thing to do. So, a stable foundation that can do everything you hear, but starting with the agile MVP method from the start.

What’s been the biggest challenge you have faced?

Definitely hiring. Finding the right people, at the right time, for the right roles, and then adapting those roles based on the people that really exist. I think we find it quite hard to find people who fit with what we’re doing and are comfortable with the ambiguity that we don’t know what we’re going to be doing three, six, or nine months from now because we’re constantly evolving. We’re doing something that’s quite new. So finding people for each role who sign up for that and can do what we are doing, that’s been the toughest thing.

The way we solved this problem was by being quick and responsive in interviewing, and opportunistic. So we met lots of people. We could decide quickly if they were a “yes” or “no”. We also found ways to give them what they needed quickly and to get to a “proceed” or “not proceed” decision quickly. This allowed us to have quite a wide funnel to look at and meet many people, then get to the right people, and to hire as quickly as we could.

What piece of advice would you give to product people starting their own company?

Think ahead on technology. It’s easy to get out demoware on MVPs and get instant feedback. At some stage that’s going to be hard to turn into a real business, so think early and bother to take the time and make the investment in building something that can actually grow, rather than potentially set out some technical debt and hurdles that will trip you up if you’re ever successful from the start.

We did that by involving a network of technical people to give us some advice on how we might need to do it in the long term, from the beginning, and that really helped us get that right.

How do you decide what to build next, and how do you test demand for it?

We listen to clients about what they want us to build next. We’re constantly showing new product ideas to clients, and even variations – almost live A/B testing on themes – and we see what’s working well, what’s working badly. We try to change everything and if it makes it better we keep it, if it makes it worse we drop it.

We’re also constantly exploring for “Holy Grails”. If five clients say the same thing, something they really want and dream of, we go out and start building it. Hopefully, it’s something that we’ve already started, and we can just move that up to our backlog of technical work and that’s what we execute next. To make sure that we’re doing it right, we take prototypes back to those clients and say, “Is this what you meant?” Lo-and-behold, we’re often completely wrong! But it gets us to the right answer faster and lets us develop the tech more efficiently. So it’s a combination of constant exploration and also prototyping.

Do you manage people differently in different functions?

Not really. I think the thing that we do is make sure everyone’s involved in understanding all parts of the business, at least to some degree. So it’s not about managing different people differently, it’s more about sharing with them in different ways. So our technical team are learning more and more about how the financial part of a business works, which I’m not sure they find that interesting! And then our commercial people vice versa. But I think having a healthy overlap between those two, makes our team work better. So I wouldn’t say it’s about different management, it’s about different growth.

Jeremy King is the founder and CEO of Attest, an insights, evidence, data, and analytics business.

Deliveroo has used Attest to evaluate new restaurant partners, in terms of the brands, the food, ability to deliver, and how well they fit with Deliveroo and its customers.

Treatwell, used the platform to gain an understanding of the detailed emotional triggers behind booking a beauty treatment, to feed into its communications and marketing plans.