My Users Aren’t Tech Savvy and Other Excuses Founders Make

Being a startup founder is one of the hardest things a person can do. From coming up with the pitch, to raising funds, hiring a team and finding your product market fit; it can be pretty daunting and frustrating. As in many disciplines, founders can experience imposter syndrome and develop tunnel vision on the product and the problems of the company. These things can cause founders ultimately make excuses about the state of the company, team and product, which must be pushed through and overcome if success is to be had. Below, I’ve compiled a list of excuses that are frequently made by startup founders, the issue they actually represent and what to do about them.

My users aren’t tech savvy enough.

This one is code for “my user interface sucks.” It’s also one of my favorites because the solution is so clear here. It tends to surface when a founder experiences difficulty training users on their products. People who aren’t “very tech savvy” manage to navigate other tech products every day from social media to their phones to streaming services — so what’s your excuse?

Features in your platform must start off by having a clearly defined user benefit, then be laid out by a user-interface designer prior to building. Missing this design and iteration step inevitably leads to an interface that is misunderstood by engineering or users or just plain sucks. The newly designed screens must have clear calls to action and purpose and make sense in the context of the rest of your product. Well implemented designs are a requirement, in addition to a clear user story, for engineering to create a successful feature.

We don’t have time for testing.

Wrong again — This always makes me wonder how many founders have time later to put out fires when there are bugs or fix features that didn’t implement the user cases accurately enough. If you’re not requiring the team to spend time on tests, you aren’t valuing anyone’s time — not the developers and certainly not your users. There are 5 steps to testing a feature successfully.

• Engineer tests the feature locally against the users story. No magic here — just run the code and make sure it works as the case was written.
• Engineer writes automated tests for the feature that fully test the code written. Don’t let yourself off easy here — test the happy path and the edge cases. When there’s a bug, add a new test case. Tests should be run by your continuous deployment system and should pass before code is released.
• Product owner tests the feature in a test or staging environment. The product owner is the only one who can fully validate the feature against the user’s need. If this fails testing or can be broken, it must get pushed back to the developers. A note here: the product owner should not be the CEO. If it is, this is the next major role you need to hire for.
• Prior to a release, smoke test the staging environment to make sure there haven’t been untested regressions in the site. A good engineer will catch most but never all of these cases so a human pass is required.
• After you release to production, do the smoke test again. Sometimes there are “gotchas” after code is released to your live site/app and another look is important.

No one used the features we built.

What this one tells me is that you didn’t spend enough time market testing the feature before building. There’s a lot of ways to prevent this; customer interviews, prototyping in no-code or low-code solutions first, presenting designs to your customers before building them and getting feedback. You’re not going to get it right every time but if this is happening to you, you skipped or skimped on this step. My favorite way to test this out is, if possible, create and implement a process for whatever you hope or plan to build and just do it manually for a while. There are many success stories using this approach from AirBNB to Facebook. Paul Graham from Y-Combinator calls this “doing things that don’t scale.” It may sound counterintuitive, but you learn things you would never think to ask about just by watching users and working with them in real time.

Users aren’t asking for X feature.

One thing that makes consulting with startups so gratifying is ideating with founders. To do this, I often pull examples from other products and industries which may seem completely unrelated to a particular project I’m working on. In doing this, it’s easy to get founders excited and thinking in new directions but after they start thinking holistically about the product, I’ve heard that users “aren’t asking for the feature” that they were just so excited about only a few minutes before. My advice is always the same — GO ASK THEM! Users don’t always know or think of what’s possible; they have to have it presented most of the time.

Frequently, when I’ve heard this is when ideating on ways to boost the amount of interactions your ‘platform’ has in it when trying to keep users engaged. The focus of your product should always be to keep users in it as long as possible and return to it as often as possible. What are the things that you’re not doing that will make your product more essential as a part of your users way of life? Ideate on them, borrow from other products and industries, and go ask them about it.

It doesn’t matter if it’s good — we’re planning on rewriting the software in a year.

Who ask money to throw away on something that isn’t good? I haven’t met a single founder yet who does but I’d love to talk to them. Founders making this excuse are typically non-technical and hiring offshore teams to build their MVP “cheaply” which is a total red herring. First off, if you are a non-technical founder who is hiring offshore or junior teams to build your product, just stop what you’re doing, go raise a round and come back when you finish and hire a professional. If you’ve never managed an offshore team or engineers (or both in this case), what you’re trying to communicate to that offshore team will guaranteed be lost in translation and will just result in frustration all around. The other issue is with the rewrite — there are so many learnings that occur during the building of the product that just get lost during the rewrite. What do your users do while you’re planning to rewrite your in-market product? Do you keep supporting the old product or just scrap it and go back to the drawing board? Supporting the old product while rewriting takes a lot of resources and going back to the drawing board means you lose revenue while you rebuild. Why even make this call in the first place? Just start by building something quality from the beginning.

Learn to understand the warning signs.

If you’ve gotten this far, you now know some of the frequent warning signs or bad habits that affect many startup founders. These issues may be common but they can be prevented and overcome by taking the time to build with intentionality, test before and during a build and committing the necessary resources to your project.

Want to know more about how we can help you navigate the pitfalls? Contact us at hello@subatomicagency.com to get started.