Building a tech product? Here's why tech isn't the most important thing...

A lot of founders think that tech is the most important part of building a tech business, but it’s not…

It’s actually product and product management. Unless you are building something super complex like deep tech or AI, tech isn’t the limiting factor.

For founders, especially non-technical, this can be daunting and there is a lot of advice and buzzwords banging around…

Here’s some product management advice and what you should expect.

USER INTERVIEWS
Nail your user interviews

Often founders shy away from user interviews. The say: “I don’t want to annoy my potential users”, “they’re probably bored of my questions”, “I don’t know how to get people excited to be involved”. It’s totally understandable but user interviews can’t be avoided.

There really is no point in building a product you want people to buy without speaking to them:

1. Just do it: sounds simple, and is probably annoying advice, but you really do need to just start doing it. More harm comes from not doing it than doing it. As long as you are respectful and friendly to your users you won’t damage your rep.

2. Don’t be scared to hear bad feedback: try to go into it with no bias, and look for a reason why something won’t work rather than will - this can be a hard balance as a founder because you need to believe but also be open to challenges !

3. Bring users into the excitement: the misconception is that user interviews need to be like focus groups– hours long and really boring. Instead, bring your users into the process, meet them for a coffee, give them regular updates on your process and ask them quick questions on LinkedIn.

4. Ask the right (open) questions: this sounds obvious but isn’t easy. The best sessions have one question, you ask it and sit back and listen. For example ‘Tell me about the last time you did X’ (related to your industry). Typically you’ll get all the answers you need from here. And you only have to prep one question.

FINDING USERS
Find your early adopters/super fans

To guarantee yourself consistent, better-quality product feedback, find your early adopters. What we mean by this is the people who will take a very early, buggy piece of software, or a not-yet-fully-formed product and use it, despite its faults.

This is different from interviewing as many people as possible to confirm you have a problem worth solving. This is for product-specific feedback, on an actual product or MVP.

Early adopters are the people who need something so desperately that they want to help you make your product better because it benefits them.

These people are needed because testing your product on large groups doesn’t actually work for 75%-80% of the bugs you want to find. You need to consistently test on 5 people to uncover all possible bugs as quickly as possible.

One way that works quite well is having small really focused groups of 2-5 people, testing on one, letting them go and then testing with another.

Generally, it’s good to interview widely to confirm your assumptions, and test small to find your bugs and confirm the right solution.

TECH
Consider whether you actually need to build an app

This is one of the most common questions we get asked by founders: “Here’s my idea, do I need to build an app, a website, or both?”

Our very product management-y answer always is, it depends. You may have a use-case that absolutely requires an app. But if it’s more “general” these are the key things to consider:

1. Ask yourself ‘Does my product have to be a mobile app or is a website ok?’

2. What do you think your users need? This is the most important thing. From your interviews, what do you think would work best for them?

3. Websites are really good for quick, scrappy MVPs– you can have something live in a couple of days with minimal spend.

4. Apps can be time-consuming and costly– Apple takes a cut of payments and getting to MVP-stage can take longer. Although there are no code app builders available these days

5. Consider the barrier to entry of your users having to download an app - is the user experience worth it ?

6. There are some contexts that require an app- you may need GPS tracking, push notifications and native features. In this case, building an app is right for your users.

7. We don’t recommend building web and app as copycats of each other - there should be a real purpose for each of them.

8. If 90% of your users access your product when on the train or when offline, then app is the right choice– it all depends on where your users use your product.

As hinted in the points above, we would generally recommend starting with a website first as it’s quicker, cheaper and easier to do, unless of course you absolutely need to build an app. If there is no way around your solution without an app go for it.

TECH
Consider whether you can build offline first

To tag onto the point above, consider if you actually need tech/code to get your idea off the ground. See if you can build a solution with the products that are already available. I’ve seen some fantastic founders who have built their MVP with just spreadsheets, Airtable, Webflow and manual processes.

For example, if you want to build a booking system for hairdressers, you could use spreadsheets, google forms and Airtable to hack something together to put in front of your potential users.

Doing this means you can test your concept before spending any real money and making any real commitments.

And, if you need funding to build something but can’t get funding without traction, build offline and show investors that you can start something without tech and start onboarding customers. It not only solves this problem but makes you look ambitious, savvy and determined.

PRODUCT DEVELOPMENT
Build as small as possible (and then even smaller)

By now, you’ve probably seen a version of the phrase ‘build as small a product as possible, test and learn’ a million times posted by a million different people (including maybe myself). The reason why we advise this is because:

First, until you start to see some traction/money coming in/users you won’t know if your product actually solves the problem you intended it to. What we see happen so often is founders have an idea about every single feature they’d like to include and set about building them. Then their product gets too big, there are too many features (most of them unnecessary at the very beginning), and they’ve spent too long and too much money building– they get to market and realise there’s no market for their product. By building something as small and cheap as possible, you can test if you actually have a market and if you don’t yet, you can pivot easily without having spent all your cash.

Second, if you’re a non-technical person working with a development agency/freelance developer, it’s really hard to communicate a bunch of features to them in the right way (and how do you know you’re right !?). It’s often the case that founders get wrapped up in trying to communicate a whole vision and overcomplicate the process. What you see as a vision 100% in your head, translates through explanation at about 70%, is then understood by the developer at around 50% and built at maybe around 30-40%. So by starting very small, it is much more manageable, you can spend more time on explanation and build one thing at a time.

Third, if you are trying to build something that is huge with a development agency with no priority over what is built first, you’ll end up building and building, and by the time you’re done with that list, you’ll have to pivot what you initially built, and start all over again. Starting small saves time, money and allows for much more agility when you receive customer feed

YOU MIGHT BE INTERESTED IN

Small plug (feel free to ignore)…

We’ve just launched a 4-week MVP service. You can find out more here.

Again, thank you for signing up to my newsletter ! I’ll be sending it out every month.

Always open to feedback, content suggestions or collaborations. Tell me your thoughts.

All the best,

Matt Jonns