{"id":19842,"date":"2020-04-20T10:30:34","date_gmt":"2020-04-20T09:30:34","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=19842"},"modified":"2020-11-12T12:45:10","modified_gmt":"2020-11-12T12:45:10","slug":"startup-fundamentals-non-tech-founders","status":"publish","type":"post","link":"https:\/\/www.marvelapp.net\/blog\/startup-fundamentals-non-tech-founders\/","title":{"rendered":"Startup fundamentals for non-tech founders"},"content":{"rendered":"

I know what you\u2019re going to think. How could I possibly know about the mistakes startups make, since I\u2019ve never run a startup myself? Well no, I haven\u2019t 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\u2019ve 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.<\/p>\n

The issue often arises when working with clients, that you have to keep a good working relationship, you can\u2019t 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\u2019re probably not going to be the next big thing and just because your friends say your idea is great doesn\u2019t mean it actually is.<\/p>\n

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.<\/p>\n

. . .<\/p>\n

Adjust your expectations<\/h2>\n

One of the first things to know is that you will need to adjust your expectations. Most people who don\u2019t 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.<\/p>\n

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\u2019t just be added in by their investor meeting next week. \u2018Everyone else has it so why can\u2019t I?\u2019<\/p>\n

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.<\/p>\n

To put this into context we need to look at the whole market. In 2008 there were just 500 apps on the App Store<\/a>. Today there are around 2.2 million iOS apps and 3.3 million on the Google Play<\/a> 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<\/span><\/a>] 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\u2019s a lot of other things vying for your users' attention.<\/p>\n

Now I don\u2019t 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.<\/p>\n

Do your research<\/h2>\n

UX Strategy is the inflexion point between business strategy and UX. UX Strategy: How to Devise Innovative Digital Products that People Want<\/em> by Jamie Levy<\/a> defines it as \u201cbusiness strategy + value innovation + validated user research + killer UX design.\u201d 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.<\/p>\n

<\/div>
<\/svg><\/div>

\u201cBusiness strategy + value innovation + validated user research + killer UX design.\u201d<\/p><\/span><\/blockquote>\n

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\u2019t 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.<\/p>\n

<\/div>
<\/svg><\/div>

\"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.\"<\/p><\/span><\/blockquote>\n

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\u2019re aiming for, it should validate your ideas and highlight what will set your business apart.<\/p>\n

During this phase, if results don\u2019t 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<\/em> by Eric Ries<\/a> - \u201citerate quickly, validate constantly, pivot when needed, don\u2019t get tied to an idea or piece of functionality\u201d. If the research shows users don\u2019t 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.<\/p>\n

<\/div>
<\/svg><\/div>

\u201cIterate quickly, validate constantly, pivot when needed, don\u2019t get tied to an idea or piece of functionality.\u201d<\/p><\/span><\/blockquote>\n

Another point to note here is that you shouldn\u2019t directly ask your audience if they\u2019d use a product or feature because they\u2019ll 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 \u2018x\u2019 number of users has mentioned the same feature).<\/p>\n

\"\"

A portrait photo of Henry Ford with the quote \u201cIf I had asked people what they wanted, they would have said faster horses.\u201d<\/p><\/div>\n

It looks like Henry Ford didn\u2019t actually say those words but the point still stands.<\/p>\n

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.<\/p>\n

\"\"

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.<\/p><\/div>\n

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\u2019t be broken down and the time just needs to be spent working on it until it\u2019s done.<\/p>\n

<\/div>
<\/svg><\/div>

\"Keep your business priorities in mind when organising your feature backlogs.\"<\/p><\/span><\/blockquote>\n

Hire people who know their onions<\/h2>\n

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\u2019t going quite as planned.<\/p>\n

If you\u2019ve already gone through 3 or 4 different teams before reading this article I\u2019m sorry to tell you but it\u2019s probably not them. It\u2019s you. I see this happen a lot where development of the product doesn\u2019t match a founder's expectations on timeframes or capabilities and so they move to a different team where the same thing happens again.<\/p>\n

One thing you need to know is that; \u2018you get what you pay for\u2019 applies to the tech world. If you want it to be cheap and fast it won\u2019t be good, you want it to be good and fast it won\u2019t be cheap. If you opt for cheap and fast the likelihood is you\u2019ll end up having to pay more down the road to fix the issues from doing it this way initially. This is called technical debt.<\/p>\n

\"\"

Three circles overlap in the middle, one says good, one says fast and one says cheap. An asterisk in the middle says \u2018you\u2019re dreaming\u2019.<\/p><\/div>\n

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.<\/p>\n

\"A<\/p>\n

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.<\/p>\n

<\/div>
<\/svg><\/div>

\"Listen to your developers and ask\u00a0which 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.\"<\/p><\/span><\/blockquote>\n

Become one with the (tech) force<\/h2>\n

As you can see the main thread here is that in tech there is almost always a compromise either to time, budget, user experience<\/a>, 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.<\/p>\n

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:<\/p>\n