Why customer feedback is the best North Star metric any disruptive team should be optimising for: evidence-based development maximises your chances of winning long term!

When we get asked to build a product, our policy is one of radical transparency with our ambitious clients. What we aim to converge on with our development teams is that we don’t need more features for an MVP, rather, we need to shorten the customer feedback loop: think → design → build → feedback → internalisation → iteration. Here’s how we go about getting from idea to MVP and full product suite as cost-effectively as possible using First Principles thinking.

Disruption

Disruption means building from scratch. Often incumbents in mature industries have biases in the way they run their businesses. Importantly, these businesses do work, and can even disrupt themselves with the right mindset. However, sometimes, it does take a completely new team with a fresh technological approach to disrupt an industry. Improvement is less about tech, and more about breaking bias. Successful businesses have a hidden treasure – tones of client feedback – and it all start here.

First Principles

Using open source technologies and frameworks is like starting on a blank canvas. The open source community is larger than any proprietary service or product, and this is the source of innovation.

Here are the questions we ask ourselves at every stage of development to ensure we’re destroying bias:

Discovery

1. What is the core problem we are trying to solve?
2. What is the best solution to this problem?
3. Who has done this before – what competition is out there?
4. What trends are we looking out for (market and technological) that we are taking advantage of?
5. How are we different? – sometimes even a 2% efficiency can disrupt a market (think Capitec acquiring devices at 0.85% fees, compared to the industry standard of 1-3%)
6. How unique is our solution – is what we are building easily copy-able?
7. Do we have the right budget to compete in this market?
8. Does unit economics of this new business make sense?
9. Can we find 10 potential customers to discuss this idea with, to see if they might buy it?
10. Here’s the million $$$ question – will someone buy this thing we’ve just built?

Design and Build

1. What is the smallest possible product we can build that someone will buy – the MVP?
2. Can we design and build this product cheaply?
3. What are the best technologies to leverage to build the product?
4. Should we be integrating with other software (typical eg. is Google SSO or payment gateways)?
5. Do we have access to the right team to build the product? Both technical and domain specialists?
6. What is your ideal customer’s feedback on your designs, pre-launch?

Go-live!

1. What are the key users inside our customers’ org saying about the MVP?
2. What are the next best features we should tackle – based on our client’s feedback?
3. What is the balance between our internal ideas, and what our customers are asking us to build?
4. Should we listen to what our customers are saying they want, or what they want but haven’t seen in the world yet?

Repeat, repeat, repeat

We understand that our initial conjecture for building an MVP is almost always wrong. That’s ok, an MVP is not meant to be the final product, but something that shows promise, indicates that this product is needed and warrants more time, investment and love.

The first cycle of this loop is the hardest – and this is true for start-ups and ambitious incumbents looking to disrupt themselves.

More articles by Dimitri:

• Serverless vs Frameworks Architecture
• Build it in Dubai
• What Does J. Powell Have To Do With Your Expensive Developer?