📹 New! Remote User Testing - Get video + voice feedback on designs and prototypes
Read more
Design Thoughts

Startup fundamentals for non-tech founders

Hurdles to avoid when working in and around the tech industry
Startup fundamentals for non-tech founders

I know what you’re going to think. How could I possibly know about the mistakes startups make, since I’ve never run a startup myself? Well no, I haven’t run my own startup, but for the past 4 years, I have worked exclusively for and with startups across a wide range of sectors. With founders of both a technical and non-technical background. And I have seen time and time again, where a lack of understanding of the technology space can lead to frustration, confusion and uncertainty. I’ve noticed the same issues come up, and that those issues could be easily mitigated if only someone took the time to sit down and explain some fundamentals of the tech industry in a straightforward manner.

The issue often arises when working with clients, that you have to keep a good working relationship, you can’t rock the boat, so you avoid telling them uncomfortable truths that may hurt their ego and lead to them deciding to go elsewhere. Things like; you’re probably not going to be the next big thing and just because your friends say your idea is great doesn’t mean it actually is.

This article outlines some of the fundamentals of working in and around the tech industry to help non-tech startup founders understand the hurdles they are likely to face.

. . .

Adjust your expectations

One of the first things to know is that you will need to adjust your expectations. Most people who don’t work in or around tech are unaware of how much work goes into products. They just see the final piece which appears in front of them as if by magic. The truth is, for that one new feature which may seem small to you, likely took weeks if not months to go from idea to implementation. Through research, design, design testing, development, evaluation in staging with quality assurance (QA) and finally, release. Where more often than not the following days or weeks are spent working on bugs and issues that have only become visible now it's live.

This can be quite frustrating to new tech founders who expect it to be an easy task to implement, for example, a chat feature in their app. Only to be met with a dozen reasons why it can’t just be added in by their investor meeting next week. ‘Everyone else has it so why can’t I?’

On top of that, there is also an expectation of getting thousands of people using your product within the first few weeks of launching. The truth is it will likely take a lot longer than you think to get to the size you are picturing in your head. Why? Because of the sheer amount of new apps and websites that are fired at users every day.

To put this into context we need to look at the whole market. In 2008 there were just 500 apps on the App Store. Today there are around 2.2 million iOS apps and 3.3 million on the Google Play store. The average person uses around 30 apps in total with 96% of their time spent on ten or so apps. [Mobile App Download and Usage Statistics (2019) - BuildFire] You could probably name these apps off the top of your head. When it comes to websites the number is even more staggering as of January 2020 there are 1.74 billion websites currently hosted. That’s a lot of other things vying for your users' attention.

Now I don’t want to be negative if you have an idea you should go for it! You never know what will come from it. You just need to know that it takes more than a great idea to make magic happen. To get and hold users attention you need to be novel and you need to fix a pre-existing pain point. This is where UX Strategy comes in.

Do your research

UX Strategy is the inflexion point between business strategy and UX. UX Strategy: How to Devise Innovative Digital Products that People Want by Jamie Levy defines it as “business strategy + value innovation + validated user research + killer UX design.” A good strategy should highlight your strongest points and attempt to mitigate any weak points and should provide you with agile, flexible methods of getting you where you want to be.

“Business strategy + value innovation + validated user research + killer UX design.”

To help you with this you need to hire a designer that knows how to conduct and analyse research as well as create beautiful designs. (I will add a note here that your opinion on design is not the same as a trained expert's knowledge of design). They can help you in the beginning with research into your users, who they are, what they like or don’t like, what other products they use and what they think of them. Finding someone good at taking initiative in how and when to conduct research can bring an extra layer of understanding and validation to your product. This person can also help with the discovery phase which is the first step in developing a great UX strategy.

"A good strategy should highlight your strongest points and attempt to mitigate any weak points, providing you with agile, flexible methods of getting you where you want to be."

The discovery phase is one of the most heavily undervalued processes in the tech industry. It goes at the start of any new project and its job is to uncover the direction of the product, the main users of that product and outline areas where any pre-existing competitors fall short. If done correctly this can set you up with a great starting place to move forward from. Most businesses do conduct discovery, however, it's usually very business focused and only lasts a few days, maybe a week max with only a basic understanding of customers and product direction at the end. The discovery phase should give you a laser-sharp focus on the direction you’re aiming for, it should validate your ideas and highlight what will set your business apart.

During this phase, if results don’t match up with what people want to hear they may discard them or give them less weight than the results that support their hypothesis. One of the best pieces of advice in this area comes from The Lean Startup by Eric Ries - “iterate quickly, validate constantly, pivot when needed, don’t get tied to an idea or piece of functionality”. If the research shows users don’t want it, then leave that functionality for now. Getting a product out there, and getting feedback from real-life humans, is more important than making it perfect.

“Iterate quickly, validate constantly, pivot when needed, don’t get tied to an idea or piece of functionality.”

Another point to note here is that you shouldn’t directly ask your audience if they’d use a product or feature because they’ll say they want it all and leave nothing out. The best thing to do is to observe them, what is their current process? What are the pain points of that process? Then look at where and how your product may alleviate those areas. Prioritise features by getting users to rank them from most to least important. Keep in mind that if 1 user has 1 feature request that does not mean you have to act on it. Keep track of the requests and set an inflexion point as to when they get acted on. (Only after ‘x’ number of users has mentioned the same feature).

A portrait photo of Henry Ford with the quote “If I had asked people what they wanted, they would have said faster horses.”

It looks like Henry Ford didn’t actually say those words but the point still stands.

Keep your business priorities in mind when organising your feature backlogs. To do this, you can use a feature prioritisation matrix. This is a task which maps out the value and effort of features and functionality, it is important here to get input from your UX team and developers. As one thing that may seem small to you may actually be massive (like the integrated chat idea from earlier). Each feature should have its own sticky note, then each team member votes (with coloured dots) for items with highest user value then for items with the lowest effort. So they should prioritise those sticky notes with the most amount of dots to be done first.

A graph with the y axis as user value from low to high and the x axis as an effort by organisation from high to low.

Sometimes you need to compromise when there are features of high value and high effort that are fundamental to the product. One way to tackle these is to try and break them down further into the smallest possible deliverables. You can then run this process again for this one feature, broken down. But sometimes they can’t be broken down and the time just needs to be spent working on it until it’s done.

"Keep your business priorities in mind when organising your feature backlogs."

Hire people who know their onions

Hire a CTO (Chief Technical Officer). Someone who has experience leading teams and has worked in tech, ideally in the same or a similar area to the one you are looking to get into. This will help you get off on the right foot, so long as they are good at their job. Knowing what questions to ask and how to properly interview for the roles you will need to fill will reduce headaches down the road. They can also be a buffer and explain the process when you think things aren’t going quite as planned.

If you’ve already gone through 3 or 4 different teams before reading this article I’m sorry to tell you but it’s probably not them. It’s you. I see this happen a lot where development of the product doesn’t match a founder's expectations on timeframes or capabilities and so they move to a different team where the same thing happens again.

One thing you need to know is that; ‘you get what you pay for’ applies to the tech world. If you want it to be cheap and fast it won’t be good, you want it to be good and fast it won’t be cheap. If you opt for cheap and fast the likelihood is you’ll end up having to pay more down the road to fix the issues from doing it this way initially. This is called technical debt.

Three circles overlap in the middle, one says good, one says fast and one says cheap. An asterisk in the middle says ‘you’re dreaming’.

Tech debt is one of the most fundamental ideas to understand when running a startup. Tech debt is like financial debt, the longer you leave it the worse it gets, it compounds interest so to speak. As that work gets inevitably tied in with other areas of the site, it gets harder to unravel. Something that seems trivial at the time can end up taking a lot longer than expected to fix. For a lot of companies, this leads to more time spent dealing with the debt, before working on new functionality or bug fixes. Tech debt can also touch more than just development, some will affect what functionality you can implement which affects the design which, in turn, affects the users experience on your platform.

A cartoon iceberg floats in water, the words ‘technical debt’ are just below the surface.

The key thing is to listen to your developers. If they give you two options one is quick and will do the job for now but may require changes in future and one is longer but will set you up for ease later. Ask them which one they would advise doing, there is always a tradeoff. On the surface, it may seem like there is an obvious option, but they could advise you to do the opposite if there are higher priorities. This is especially true on a limited budget or time frame.

"Listen to your developers and ask which one they would advise doing, there is always a tradeoff. On the surface, it may seem like there is an obvious option, but they could advise you to do the opposite if there are higher priorities."

Become one with the (tech) force

As you can see the main thread here is that in tech there is almost always a compromise either to time, budget, user experience, functionality etc. The important thing is to be decisive, to make informed decisions by tracking metrics and conducting thorough research, not only at the beginning but continuously. By getting your users involved at every step of the way you can reduce the number of surprises when new functionality is launched.

One of the best things you can do is to prepare and immerse yourself in tech. Do your homework. Read about the different areas of tech, about user experience research, about agile vs. lean methodologies and QA. Make it your aim to read at least one article about something in tech once a week. Some good books to start with are:

. . .

To summarise

Understanding things will take longer than you think.
Don’t compare yourself to Instagram.
Make informed decisions.
Listen to the experts.
Involve your users.

Have fun and celebrate the little wins.

Belfast born, London based UX Designer at WhiteSpace who has no self control when confronted with doughnuts and occasionally writes design related pieces on Medium.

Related Posts

When designing your marketing materials and website, it can be easy to rest on your laurels. However, if you don’t keep up with market trends, your materials will quickly become dry and outdated. As we charge through 2021, it’s essential to consider what design trends are on the horizon and which are here to stay. For the rest of 2021,… Read More →

We all have our blind spots and biases regarding the application of thought towards a problem or solution. Depending on the strategic outcome you’re looking to reach, resources available or time constraints, it can be easy to lose sight of the overall user experience. In doing so, we often rally behind ideas that get us towards the shift of a… Read More →

Design systems let organisations solve product problems in a structured and guided way. Whilst they can take many different forms, all design systems aim to codify certain principles and practices cross-functionally, letting you work more effectively, build and iterate at scale. In the first article of this series, we’ll explore what having a design system means for your organisation, the… Read More →

Categories