Are You Building Your Product? Here's Some Advice From Us.

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, tech isn’t the limitator.?

For non-technical people this can be daunting and there is a lot of advice and buzzwords banging around…?

Here’s some advice from our Lead Product Manager and myself on product and what you should expect.?

1) Nail your user interviews:?

Often founders shy away from user interviews. We often hear: “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.?

I’ve rattled on about the benefits of speaking to users on LinkedIn for the past two years ??? but there really is no point in building a product you want people to buy without speaking to them.?

Our advice would be:?

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. We find 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 ??.?

2) 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.?

3) 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.?

4) 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:?

Firstly, 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.?

Secondly, if you’re a non-technical person working with a development agency/freelance devwloper, 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.?

Thirdly, 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 feedback.?

—-----------

I hope these tips are helpful, please feel free to reach out to myself or any of the team if you have any further questions !?

–– Victoria and Matt?