How should I choose what to build?

How to build products that matter quickly and cheaply

Christina Stejskalova

Published in

Agile Insider

5 min readJan 7, 2021

“I need a dev team”
“I need to build an entire app in react in 1 month to test my product”

These are common quotes I hear from 1st time entrepreneurs. I felt the same. The first product I built I insisted on learning how to code, spending hours designing a loader in javascript (I am still immensely proud of the result, visible here) to make sure that nobody could fault me for not being an engineer. But whilst I’m proud of my loader, was that really the best use of my time? What opportunities did I miss whilst building the loader?

As an entrepreneur who failed by pursuing the above mindset (need to have eng/need to build product before I can show), I thought I would write an article reflecting on why I changed that mindset with the hope of inspiring entrepreneurs to realize how freeing for your product development realizing you don’t need to rely on eng is! (Gosh! What a sentence!)

The RAT (Riskiest Assumption Test) comes first

My most valuable lesson as an entrepreneur is that RAT test comes first. I learnt this 6 months down the line, with a built product, and having run 30+ A/B tests later the realization that I had not tested my RAT before building.

This is probably the most common mistake of all time. As an entrepreneur, you are supposed to start with a problem, but by god did I jump into the solution. With the lean startup mindset in the back of my mind, I was telling myself, I did it, I built an MVP of my website, and we got users so it worked. WRONG!

I could have done less, quicker, and if I had I would have likely built a successful company instead.

Here’s how to actually build an MVP that tests your RAT:

1. Value versus Complexity Quadrant

Product managers use the Value versus Complexity Quadrant to prioritize product features. The theory looks a bit like this:

You end up prioritizing features that are in quadrant 1, easy to build and high impact. Makes sense huh? I think we can do better. This quadrant assumes resources are static. That you need to use the same resources to build your product and that’s why you forgo a higher impact product feature if it takes more resources to build.

In my head, the goal of a good product manager/entrepreneur should be to figure out how high impact product features can be moved from quadrant 2 to 1. And guess what, this is always possible, and if not, it merely means you aren’t making your product features MVP enough.

You see, for me, these product features are all still experiments. Given they actually haven’t been built, how do we know if they actually deliver the value we expect?

If we incorporate the MVP mindset there is always a way we can move features from box 2 to box 1

But wait, if something is more impactful, are we sure we can’t build it with less effort?

3. I hate articles that talk theory and don’t provide examples

Let’s provide an example. In the past company I worked for we were going through precisely the value complexity quadrant when prioritizing new features. Because the complexity piece was fully reliant on engineering resource, some product features, like notifications that were high impact where not being prioritized.

As a result, our product continued to fail. We kept on building cool features, but none of them mattered because we weren’t getting people into the app. You could argue that this is down to wrongly assigning impact, but once you assign them resources that’s that.

Well, not for me. I decided the only way we could do the highest impact intervention would be if it wasn’t built like a full product feature, but as an MVP. I would have to hack it.

And boy did I do that. I used our A/B testing framework intended for special use notifications to start my notification reports. Instead of having audiences automatically selected I used SQL queries to pull the audience. Yes, this meant the list wasn’t real time, but the impact of that was negligible.

I created behaviorally infused versions of my copy, confirmed by both legal and content strategy in 3 days.

Overall, in 1 month, I managed to conduct 12 A/B experiments with notifications without using a single engineering resource, and more interestingly, involving teams like marketing, content strategy and legal into product development.

The outcome: 4X increase in attendance of the events

The other outcome: empowering a team. A product feature created by legal, content strategy and data science.

That’s the insight here.

In the world we live in today, with the explosion of no code tools, it’s seems myopic that we feel engineering is the end all and be all of product development. If we truly want to empower people to build products, to become entrepreneurs we should encourage the MVP mentality. Perhaps you can’t build the prettiest, most scalable product, but until you are sure your product will deliver valuable product, don’t dump money into building an expensive engineering solution.