We’ve been working on a bunch more UI components the past two weeks. They’re all part of the core for the MVP for Thymer, but one thing we won’t have time to look at before the launch is making these work on smaller devices like phones.
Part of the process of building an MVP is that we inevitably have to say no to things we really care about. In our case one such aspect is starting with just one platform: the desktop (specifically the web). The first version will be unapologetically desktop-only.
The USP of Thymer is that it works like an editor/IDE. As planning and brainstorming are creative processes, we think being able to simply type, select, copy/paste and change your ideas or schedule as if it was text is a big boost in productivity.
We want to solve this one problem really well. In our case, the UI really matters. If we decide to build something for desktop, iPhones, iPads, Android watches etc etc from the get-go however, not only will we take forever to launch, but we’ll need to take shortcuts at some point to launch at all.
One such approach of building for all platforms at the same time is by building something which is mobile-first. But mobile-first is all-the-rest-last. Instead of coming up with the solution we think is best and then building that, we’ll end up shoehorning a toy UI onto the desktop just to match the constraints of a mobile device.
Of course not having a mobile app from day one is far from ideal. We all work on the road from time to time on our mobile phones. Yet a lot of the real creative work we’re building Thymer for gets done behind a laptop or something else with a keyboard and mouse/touchpad. To solve that problem really well, we think it’s worth delaying some sort of solution to work on a mobile for a while.
So we have the choice: hack something mediocre together for the launch as quickly as possible that works on all platforms, but is perfect for none. Or build exactly what we envision, but start with one platform.
Some of the components we’ve worked on the last two weeks: panels and a command palette. UI components we think will be super productive on desktop.
These choices are hard to make when you need to decide what to launch with. In the end it’s better to start with making something smaller in scope but which you think is really great. We need those initial fans who really like the solution we’re building to get off the ground. With some cross-platform responsive app approach we can’t build the kind of editor we want, and it will just look like all the rest.
Once we know people really like the concept, we can look into options to make it easier to work on the road. Because of the way the app works in the backend, it will be quite easy to add offline support so it’s no problem to keep working on your laptop on a long flight. As for mobile, we’ll still have to look into that later.
Because we want to create the best experience we can for desktop without the constraints of it needing to work on mobile, it will most likely be a completely separate app (although we can reuse the API/backend of course). That way we can design the other way around, too: come up with the best possible user interface controls for mobile, without having to stick to desktop concepts. Plus this might make it easier for us to outsource work on the app for a specific platform if we want to go that route.
We also kind of like the idea of a “companion app”. A smaller version specifically designed for mobile use. Rather than cloning every exact feature from the desktop version for mobile, we add just the things you might need most on the road and make those very easy to use. Like looking something up or quickly jotting a thought down which you can then work on once you’re in front of a laptop again.
But all of that is for later. We first want to focus on building something great for just one platform and see if people like the idea in the first place.
Most startups fail. Some startups don’t launch at all. Maybe the founders get into a big fight, or they lose interest, or the product is too hard to build, or something else throws a spanner in the works. Other startups launch but don’t get any traction. Either they get no signups or the users don’t like the product. The founders then get discouraged and quit. Then there are startups that pass the first two hurdles but stumble at the third hurdle: they launch and get a bunch of happy users but they fail to monetize. Failure at different stages but failure all the same.
With our app we really want to pass all three hurdles: launching, marketing, and sales. There is some luck involved and we can’t discount the possibility we’ll fail as well. Things beyond our control can take us out. That’s part of the game and we accept that. What we don’t want is to fail because of unforced errors. We don’t want to do dumb stuff that predictably results in failure. We want to learn from other startups what works and what doesn’t.
I’m going to describe three different startup failure scenarios that I see time and time again. I’ve anonymized the stories because my goal here isn’t to make fun of people who failed but to analyze what happened so we can learn from it.
Our fictionalized founder makes three apps over the years:
a desktop app that helps you organize your music collection on Linux
an iPhone app that tracks and charts your grocery expenses
a job listing webapp
The projects fail for different reasons but with a shared root cause. I’ll get to that later. First let’s go over these startup attempts.
Attempt 1: Linux music library app
Two common pieces of startup advice are to (1) build with the skills you have and (2) solve a problem you understand well. Our protagonist takes this advice very literally and decides to make a desktop Linux app. He has written software for Linux before and he knows he can make a better app for organizing your music.
Our heroic founder spends nights and weekends to get his music library app done. He starts coding in c++ for performance reasons, but eight months in he decides that programming that way just takes too long. The product architecture got a bit messy, so he decides it’s time for a rewrite in Rust. He doesn’t know Rust, but it’s a cool new language with smart memory management that he wanted to learn anyway. Fast forward a year later and the app kind of works. At this point the founder no longer has much passion for the idea. He’s not convinced people will buy his app. Working for two years straight in isolation is a long time and he decides he it’s time to launch. He spends two days on a website, but our protagonist has no web design skills and it looks pretty bland. He submits his site to Hacker News, reddit, and sends the link to some friends.
Crickets. His website gets a few dozen visitors. A download or two. Traffic drops to zero after a few days. Frustrated, the programmer abandons his project. He tells himself that failure is inevitable on the road to success. That failure isn’t real failure if you learn from it. He reflects on why his startup didn’t take off and concludes that the fundamental problem is that his app didn’t have a big enough audience because Linux is too niche. He figures he should have made something for “regular people”, instead. He also decides he should make something simpler.
With full determination he decides to try again.
Attempt 2: iPhone app for grocery expenses
Our founder has no particular passion for grocery phone apps but he figures that everybody shops for groceries so it should be a good and large market. If he charges $10 then for every 0.01% out of a billion iPhone users that buy his app he’ll make a million dollars (less 30% Apple fees and taxes). Previously the founder struggled with distribution and now he has Apple to take care of this for him. He also doesn’t need to worry about invoicing, credit card payments, or any of the other annoying business-y stuff anymore.
Our protagonist starts building. A year and two rewrites later he’s happy with the product and submits his app for review. His app is approved and soon after he gets the first sale! Making your first dollar of internet money very exciting. Then again, a trickle of downloads and one $10 sale per week won’t cut it if you need to make a living. But what to do? Lower the price? Ads? Rename the app? Change the logo? Translate the app to multiple languages?
Six months and many experiments later our protagonist is ready to give up. He can get more downloads if he charges 99¢ but he’s still only making beer money. Switching to in-app purchases results in more downloads, but getting people to upgrade is no mean feat. A few mean app store reviews later he’s completely done.
Okay, lesson learned, he thinks to himself. Next time, he’s going to make something SIMPLE with BUSINESSES as customers.
Attempt 3: job board
With renewed spirit our founder gets to work. Where previously he spent the better part of a year to get a prototype going now it’s just a matter of weeks. Job boards are pretty easy. What do you need? A place for people to look for jobs in their region. Search and filter by keywords and requirements. Done. What else? A backend for employers to submit new job openings. He decides a job listing costs $100 for 30 days. Slap a credit card form on the page and done.
This time our founder has a plan to get users. He’s going to contact hundreds of companies and recruitment agencies over email and LinkedIn with his pitch. He figures that by charging less than the established players he can win their business.
No dice. Companies just don’t want to advertise on an empty website. And job-seekers have no reason to visit an empty job board either. Catch-22. Our protagonist decides to reach out to a more experienced founder and asks for advice. The secret, he’s told, is to cheat. Create fake listings, fake users. Fake it all. Once you’ve got real companies and real job-seekers you can phase out the fake traffic.
The founder can’t believe what he just heard. That’s an ethical line he doesn’t want to cross. Disgusted, he concludes that startup life just isn’t for him.
Retrospective
Three attempts over many years amounted to nothing. Every time the founder believed he learned from his mistakes and would surely succeed next time, but he was wrong. The founder didn’t get anywhere because he learned only specific lessons: don’t make a Linux app; reaching the top of the App Store charts is hard; you can’t bootstrap a marketplace from nothing without cheating. The founder didn’t discover the root cause of his startup troubles and consequently didn’t learn anything of value. He could try five more times and he would continue to fail if he did.
The fundamental mistake this founder made is that he tried to arrive a good startup concept by reason. You can come up with reasonable sounding arguments in support for the most hopeless ideas. “Good arguments” therefore carry no weight at all.
Instead, the founder should have looked for evidence. Have other people found success with commercial desktop Linux apps for consumers? If yes, how did they succeed? Did they bootstrap, self-fund, or take VC funding? How did they find an audience? Can you find the wreckage of other people who tried what you’re about to do but failed? Why did they fail? If you can’t find success stories that’s big red flag.
It’s easy to explain failure with hindsight. There is no commercial competition for Linux desktop apps because Linux users don’t pay for software. The Apple App Store by contrast is highly competitive. You have to figure out why apps succeed and fail in app stores before you spend a year on an app of your own. You need a captive audience of businesses and professionals in search of jobs before you start on your job board or you’ll fail. But these specific explanations are not important. What matters is the processof looking for evidence that supports or invalidates your startup idea before you commit. The alternative is magical thinking and it looks like this:
The diagram doesn’t look like this in the founder’s head. The founder has all sorts of strategies and plans that sound great, but plans that aren’t backed up by evidence are just wishful thinking. If you remove everything based on wishful thinking what you’re left with looks like the flow chart above. Build. Launch. Pray. Give up. (Repeat.)
The founder also made many other mistakes. But so what? Everybody makes mistakes. Mistakes can be fixed if your startup gets the important things right. Your best best is making an original product for an established market and by applying sales/marketing strategies that are known to work.
Written like this it seems trivial. But it’s not. I see an endless amount of magical thinking by founders who earnestly believe that just making something and hoping for the best will work out for them. I’m not judging, though! We’ve also spent years on hopelessly flawed products. When we failed we totally deserved it.
I mentioned in the introduction that we intend to pass the three startup hurdles of launching, marketing, and sales. For each of these hurdles we’ve collected clear indicators that our general approach should work. We’re intentionally a “single miracle startup“. We’re taking an educated gamble with our product, but our marketing and sales will be conventional and straightforward. Our plan may fail, but we have a real plan.
When you’re working on your first prototype for a new product you’ll inevitably come up with many wild ideas. It’s just part of the creative process. If you are a disciplined you won’t let yourself get distracted by actually building any of them, but it’s fun to think about what your product could be like one day.
Right now we focus 100% on what is strictly necessary to get a prototype done. The prototype has to have just enough functionality for us to get useful user feedback, but no more. Then we can iterate based on that feedback and fix flaws in our design.
That means we can’t add any of the stuff below to Thymer. Not yet, anyway.
Blog plugin. Use Thymer editor to write simple text based posts + maybe pictures. Render to static .html to publish.thymer.com or something like that. Maybe let users write public and private blog posts. If the Thymer editor is really good and you already have your notes in it, being able to share them makes sense. You could also share posts privately, with end-to-end encryption. Users would then need to enter a password to decrypt the shared note. It’s an easy plugin to write, and maybe it’s something people would like.
Kanban board plugin. Instead of rendering Thymer tasks as a vertical task list we can render them horizontally with tiles like a Kanban board. Add support for drag&drop. Enjoy easy planning.
Thymer is effectively a tree editor. Allowing users to view/edit their data in different and visual ways is probably an easy win for us.
Transclusions. A transclusion is when one document appears partially inside another document. Digital documents don’t need to be strictly linear, and it would be very cool to have something that’s more powerful than a plain hyperlink to another part of your Thymer document. We already need to make something where a planning view (an ordered list of things you plan to do next) can have items from anywhere on your document on it. Generalizing this concept and adding full-blown transclusions to Thymer might be worth it, because it unlocks opportunities down the road.
End-to-end encryption. Thymer is an offline-first app. You download all your data when the app loads, and it syncs in the background when/if you’re online. Because the app has to work offline the server doesn’t need to get involved during normal operation. That means we could just encrypt all data locally. Then the server would only see the tree structure of your document, but nothing content-wise. The major downsides here are that we won’t be able to offer server-side search, a practical API, or 3rd party integrations if the server can’t read the data. Personally I strongly favor apps that put encryption front and center. We’ll have to wait and see what the beta users think.
Roadmap plugin. Thymer will get a personal schedule where people can add tasks they plan to do Today, Tomorrow, Next week or whenever. But sometimes you want to do higher level and long term planning. We could make a plugin for that. It’s unclear at this point how it would work exactly, but if you have 5 or 10 people in a team you want to have some kind of overview where you can see what’s happening in broad strokes. Maybe this overlaps with Change History and Meeting Mode below. I don’t know.
Poweruser console. When you’re working with your own software you do bulk actions all the time. You find some objects based on some criteria, and apply some changes with a for loop. A REPL or a browser’s debug console are huge for productivity, but consumer apps never offer something like that. Why not? You can tediously make changes with point and click. If you’re lucky the app allows you to bulk move/delete, but that’s where it ends. I’d really like Thymer to have a REPL. Then users can do whatever they like with their data. Users of productivity apps have their idiosyncrasies, and the more Thymer can accommodate how people like to work the better.
Change history. Some way to see a what changed in a condensed way. If you get back from a holiday you want to see what people have been working on. How has the schedule changed? What items have been deleted/abandoned? Who is currently working on what? What decisions have been made in your absence? Ideally, you’d get some kind of executive summary that isn’t too long. Because the Thymer document is a tree it’s reasonable to to assume things higher up in the tree are more abstract/high level. Maybe a summary view can condense changes based on that.
Emoji Flags. People want to use their task list in different ways. We won’t be able to anticipate all our user’s needs, but we can provide people with options to organize their tasks to their own liking. We can store arbitrary metadata in tasks. Allowing users to choose their own status emojis doesn’t seem like a big stretch. Want to give a task a ⌛ or 🐳 status? Sure, why not.
Meeting mode. During a meeting some tasks get deleted, new tasks get added, tasks get assigned and reassigned, and people’s schedules get changed. You want to see what has been changed during the meeting separately from other changes made to the Thymer document throughout the day. Ideally meeting notes that contain the rationale get linked to the changes made to the Thymer document. I don’t think it makes sense to have meeting notes that duplicate the changes made in the Thymer planning. But when there are no meeting notes at all the “why” goes missing. Somebody who hasn’t attended the meeting should be able to see what has been discussed and what has changed as a consequence. I don’t think there is any product out there that gets this right, so it’s probably more difficult than it looks.
Any project, even something as simple as a todo list, will grow in scope if you let it. You can’t just add every random feature to your product. Your product will lose its cohesion and you’ll never launch. But you can write down all your half-baked ideas. Once you’ve got some users go back to the list and see if you can actually make some of your wild ideas reality.
Your app need a good answer to the question: “Why not go with the established competitor’s product?”. That’s what your Unique Selling Proposition (USP) is for. This is especially important when you start out, because a new product has fewer features than the competition. You also don’t have brand recognition. People buy Apple products just because they’re made by Apple. A startup doesn’t have that advantage.
Your product is also likely to have some serious shortcomings. It takes years for software to get good, so you need something to compensate for your lack of features, lack of brand, and other ways in which your product isn’t great.
You can try to compete on price. Just charge less than everybody else, right? Except, this can backfire on you in two ways. One, you send a signal that your product belongs in the “budget” section and is therefore worse than other products. And two, the cheapest products get the most difficult-to-please and most demanding customers. I’m not entirely sure why this is, but my hunch is that people who look for the cheapest products have a negative disposition. Maybe they’re afraid they’re getting taken advantage of, or maybe they resent having to pay for software in the first place. When you charge more you get customers that look at the value provided by your software and decide based on that to go ahead with a purchase. For the first kind of customer any price is too high. The second kind of customer will be happy if you explain in plain language what your product costs and what they get in exchange. You don’t want to be the most expensive product in your market and you don’t want to be the cheapest. Just be somewhere in the middle. Maybe somewhere the lower 3rd, that way you can easily raise your prices as your product gets better without pricing yourself out of the market.
Can you distinguish yourself with some really cool feature? Probably not. It might work in the beginning, but once you get some success your competitors will notice. Established businesses have more resources and most features can be copied. Usually competitors will make a feature that’s equivalent and not exactly identical, but it amounts to the same thing. The one feature that made your product unique has been commoditized and you go back to square one.
You also can’t distinguish yourself based on “universal benefits”. You can say your product is “fast”, or “easy to use” but every competitor will say the same. You can say your product is “secure”, but even competitors with the worst security practices (and the record to prove it!) can put any number of logos on their website that prove their product meets every industry standard. Ever noticed how companies with terrible customer support have these Customer Service awards plaques on their website? You should absolutely work your hardest to provide great service, but to really distinguish yourself you need more.
So you can’t compete by having more features, you can’t compete on price, you can’t compete with cool unique features. If none of these approaches are good, what can you do?
To differentiate yourself in a way that lasts your product needs to be something the competitors explicitly are not. Good products drive a wedge in a market where customers have to choose whether they want a product of Type A or Type B, but they can’t choose both. If you segment the market intelligently you’re the first and therefore best product in this new subcategory. This puts you as a new startup in a terrific position.
If you’re going to compete with Gmail you don’t want to be the product that’s cheaper (Gmail is already free) or the product that’s faster (Gmail used to be fast, too) or the product that has the most features. You want to be the product that is about privacy. No ads. You fight newsletter spam and email open tracking and other bad practices. What is Gmail going to do? Nothing! Gmail is an ad-based product, after all.
With Thymer we’re boldly choosing a text-based UI. Many people, like us, use text-based IDEs all day. It’s the kind of software interface we like, so odds are, other people will like it too. It’s not a feature our competitors can just copy, because it defines what our app is. If we succeed I’m sure people will try to copy us outright. That’s inevitable. If our app is good enough clones won’t hurt us much.
There is a final reason why it’s important to have a clear USP for your app. You want to be the best product for this new segment you’ve created. Any time you think about adding a new feature or adding some text to your product page you can ask yourself if it fits with your core theme. This helps you focus on what matters. You don’t want to dilute your vision, you want to make it stronger. It will put off many people, but those who like it will end up really liking your product. When you start out, that’s exactly what you want.
You know you want to start a startup, but you don’t know what to build. Maybe you have notebooks chock full of ideas but you don’t know which ones are good. Maybe you don’t have any ideas, because it feels like everything exists already.
You’ve googled for tips but discovered that most articles on the internet about validating startup ideas are aimed at startups that seek Venture Capital. Startups with Venture Capital can throw money at problems. They can buy growth, features, and positive press. When you’re a bootstrapped startup you won’t be able to outspend the competition which means you need to be scrappy and strategic. It’s a different game.
Bootstrapping refers to the (physically impossible) trick of pulling yourself up by your bootstraps (etymology). As a startup metaphor it means building a startup without any resources. It’s possible to start a web business from nothing because your only expenses are web hosting, a domain name, and a laptop. You need technical and business skills, but you can learn for free. There are no real barriers to entry. That’s great for society but it also means you’ll have a good deal of competition no matter what you decide you build. Bootstrapping is possible, but it’s not that easy!
We haven’t written much about idea validation so far because it’s so subjective. What do you want to get from the business? Do you primarily want to make your customers happy? Do you want to solve interesting technical challenges? Do you just want to make money? Do you want change the world for the better? Do you want the freedom of working for yourself? Do you just want the excitement? The satisfaction of forging your own path? Everybody has their own priorities and the only thing that matters is that you know what yours are.
Also, everybody has a different skills, abilities, and resources. Do you have a lot of time to get your business of the ground or do you need to launch ASAP? Can you self-fund to a degree, or are you broke? There is a large personal component to this. What may be a good idea for you might be an awful startup idea for me.
I say all this because I want to stress how subjective this all is. There are very few right and wrong answers and we certainly can’t tell you what to build.
That said, I’m not a total relativist. Some startup ideas are brilliant and original and I feel foolish for not having thought of them myself. Other startup ideas are objectively terrible and founders would spare themselves a lot of grief if they thought their business through before they invested a lot of time and money into it.
Essentially, you want to figure out if your startup idea has legs before you commit a ton of time to it. That’s all validation is.
You have two things to validate: (1) if people want to use your product, and (2) if it makes sense as a business.
PRODUCT VALIDATION
What makes your product unique (USP)?
Why should people buy your product and not somebody else’s?
You can’t just copy a product and add 1 cool feature.
Do users care about your USP?
Can you build a prototype in a reasonable amount of time?
Can you get away with building just a few core features?
The longer it takes to build your first prototype the more confident you need to be that your idea is good.
Is the product scope reasonable?
You can’t win by simply building more features. That’s a game for VC backed startups.
Small products are better suited for bootstrapping.
Do you have the necessary technical skills?
Do you know where the technical execution risks are?
BUSINESS VALIDATION
Can you find enough users?
Do these people exist?
Do you know how to reach them?
Will users buy your product?
Do you have free competitors?
Is the market very crowded?
Do you have successful bootstrapped competitors? If not, why not?
Can you explain to users how your product is better?
Can the competition easily copy your product?
Can you charge enough money?
Figure out how many customers you need for your revenue goal
Do you need to compete on price or can you charge a premium?
Can you grow by self-funding?
Can you automate your sales/onboarding/growth process?
Does this business suit your personal strengths?
You want to put your strongest skills to good use
Will you stay passionate about it in the long run?
Any legal liabilities/risks?
Yep, this stuff is prosaic. You need a product and you need customers. Not exactly rocket science, right? And yet, making an effort to think your idea through is vital. The questions are basic but the implications of the questions are subtle and can easily trip you up.
You can figure out roughly how much you can charge for you product by looking up what your competitors charge. When you start out you want to be in the lower end of that range. You don’t want to to be the cheapest product because the cheapest products attract the most price sensitive and difficult to please customers.
Some people will tell you that you can validate a business by slapping a marketing page together and asking some people if they would pay for the product if you build it. It’s just a matter of cold emailing some people (or LinkedIn/Twitter message) and you’ve got your answers. I don’t think it’s that easy. If people are enthusiastic when you describe your startup to them that’s a good sign, but it doesn’t prove much. If you make something for an established market then you already know customers exist provided you make a good product. And if you make something really original you can’t explain what it is — you have to show people. But you have to build it first (or a prototype at least) in order to do that.
You won’t know for sure if people will actually pay for your app unless you put up a credit card form. Words are cheap, after all. But before you get to this point you have to build the product and find users. No real shortcuts here, either. If you’re good at sales maybe you can convince people to give you money for a product that doesn’t exist yet, but that’s not my style.
You can work out how long the first prototype will take by starting with the hard parts. If you can outclass your competitors by solving a hard or hairy (or schleppy) problem that will give you a big edge. You don’t want to spend weeks or months building scaffolding only to discover you don’t know how to make the thing that would make your product great.
You can figure out if your USP makes sense by working on your hero message. The hero message is the big text at the top of your product website that explains what your product does. Try to capture what makes your product unique. For the thymer.com splash page we explain how we’re different: it’s an editor, and we explain in two sentences what it does (tasks and planning) and what the target audience is (makers/creatives). We collect email addresses at the bottom. If we have a few hundred people waiting to try Thymer by the time we got a first version going then we’ll be able to get a ton of valuable feedback that will help us figure out if we’re on the right track.
The bottom line is, the more answers you get to the questions above the more you “de-risk” your startup. Some answers you can get by googling. Other answers you get by talking to prospective users/customers. At some point, though, if you’ve thought hard about your idea and if you haven’t found any critical flaws, just go ahead and commit. Take the time to build a solid prototype and discover if the app works as well in reality as it did in your head.
Although we haven’t done much marketing for Thymer.com yet, we are getting a steady trickle of new email signups for the private beta. It doesn’t prove that we’re on the right track with Thymer, but it suggests that that there are at least some people who want to try an app that looks something like this:
The big trend in web design in the last decade has been towards simplicity: bigger fonts, more whitespace, more visuals, mobile first, and fewer buttons. With Thymer we are heading in the opposite direction. Thymer is keyboard focused, information dense, programmable, and feature rich.
I get why the trend is towards the simplest possible apps. Simple apps are easy to make and easy to support. And the world is huge so there is always demand for apps that get the basics right. Apps like these can look brilliant during the first 30 minutes, and then you run into the first limitation. Soon after into the second one. Then you wish that you could see more of your stuff, but you can’t. These apps are made primarily for mobile devices and on a big screen you just get more whitespace. You want to do some bulk actions, but that’s unwieldy or impossible. Even productivity apps have followed the trend where usability is sacrificed for visual appeal. It makes perfect sense, though, because it’s screenshots that sell your app, and dense apps look intimidating.
We’re taking a big risk by running counter to the trend. We know that there are many programmers who love apps that look like Thymer. The runaway successes of Sublime Text and VSCode are proof of that. Our hope, still unsubstantiated, is that there is a much larger group of people out there — not just programmers — who want a productivity/planning app that’s designed like an IDE. People who aren’t familiar yet with something like a Command Palette, but who are willing to try something new.
Design trends change. First skeuomorphism was cool, then flat design was the only game in town. Maybe, in the future people will demand apps that are simple on the surface but not at the expense of functionality. A new trend towards text-first interfaces for applications that are mainly about text, perhaps.
We’re deep into code now. A good deal of plumbing left to finish before we have something that resembles a buggy prototype. Then we finally have something substantial to show people and then we can ask people on the beta email list and here on 80daystartup what they think and what kind of features they would like to see. For me this is one of the most exciting parts of building a new product. Ideas that started as sketches on napkins and pizza boxes slowly start to take shape.
Starting a business is always a gamble. I still think the odds are better than many assume (not starting one is a gamble too, in a way), but in the end you just won’t know for certain if it will work until you try.
To reduce the “risk”, a lot of advice focuses on making smaller bets and getting quick wins.
It seems a lot of this advice is taken to mean you should always try a “safe idea” to maximize the odds. Try to interview people and see what their problems are. Maybe do some consulting or freelancing instead (vs building a product). Perhaps start an info-product, something easy to make, make sure it doesn’t take too much effort to build. Instead of thinking about a problem, think the other way around: what could get you “rich quick”?
I think this narrow focus on these “safe ideas” is a mistake.
It’s totally okay to have a small scope for your initial idea. It’s very important to be able to launch relatively quickly, because you have no idea whether your product will really work. But that’s always the case, “safe idea” or not.
The biggest problem with reducing the space of ideas people think they can work on is that you stop working on what you feel you have to. It’s great if you really love one of those “safe ideas” of course, but if it feels uninspired or it becomes so much about the quick win, then we we stop dreaming about what we actually want to build. And I believe it’s working on what you feel you have to that really increases your chances of success, even if that’s a harder problem than the “safe bet” easy-win get-rick-quick idea.
You’ll automatically know when you’re working on something and your heart isn’t really in it. In fact, your customers will know it too. Your product won’t stand out, it will feel bland, look the same as the rest, uninspired.
You know that problem that you just have to work on, because it’s where your mind drifts when thinking about solving problems during a walk/shower. It’s the thing you can still work on even if you’re tired (not that you should, but you could!). That means you’ll be able to keep working on it, which is important if you want to succeed. Especially because in every startup there will be many dull and boring tasks which need doing, and it’s hard to stay motivated enough to do all the parts which are boring to you if you don’t really want to work on this problem.
Another advantage of working on your dream idea is that will want it for yourself, so you know exactly what to build. Or maybe it describes yourself. Or it’s a trend you’re part of which is starting to emerge and you think more will follow. It’s hard to time the market anyway, and just coloring within the lines and building similar things to what’s out there is not going to make it easier. Might as well work on your dream and make it stand out enough.
Another important reason to work on your dream idea rather than a “safe idea” you don’t really care about, is that if it actually succeeds, it will become a relatively big part of your life. We can only work on so many ideas after all.
Many of these ideas are discarded because they might feel too unrealistic (or the complete opposite, they might feel like a “hobby”). But those are actually the most interesting. Yes they can completely fail (the advice of finding out quickly is still very important!), but they can also really push things forward. A lot of really interesting and successful things wouldn’t have existed if their creators would have stopped dreaming and just stuck to something “safe” instead.
Work on something you have to, get a V1 out to customers as soon as possible for the type of product, and see if they love it. Worst case you’ve worked on something you had to anyway, no regrets, and move on. Best case they’ll love it and you’ve really added something new to the world.
In this post I want to stress the importance of having an app that is really good. As good as you can possibly make it. Ideally your app blows the competition out of the water in a side-by-side comparison. This isn’t just about UI/UX design and features. It’s about whether your app solves a key problem much better than anybody else. Your prototypes and MVP won’t be that great, and that’s to be expected. You make those first versions to gauge potential. You have to work towards making a truly great app though, and in this post I’ll explain why I believe this is so important.
There are some businesses that do well without having great software, just by being great at marketing and sales. So why not just do that? You can hustle. You can buy ads, build a big following on social media, do cold outreach and email 10.000 people, write SEO pages, plug your app on youtube and do podcasts. That all works[1]. You can get many people to try your app with persistent marketing. Despite all that, if your app doesn’t provide enough value to people your startup will struggle and not really take off, no matter how hard you hustle. This is because the world is huge and the fast way to reach many people is by word-of-mouth. Your users have to be so thrilled about your app that they’ll tell their friends about it. Your app should have an R0 above 1, if you catch my drift :). That’s how you get explosive growth.
You can ignore what the market is telling you. You can just power through and hustle. Even with a mediocre app you’ll still find customers with persistence. You can even create a profitable business that does well year after year. This works best in markets where competition is weak and nobody has made a great product that users love. Those are markets just waiting to be disrupted. Just a matter of time until that happens.
For B2B startups having a great product is less important than for B2C. There are two reasons for this: 1) business software is more expensive which means you can just hire sales staff and 2) people don’t get as enthusiastic about business software which means your competitors are likely to struggle with word-of-mouth growth just like you. But even B2B markets get turned upside down by upstarts with wildly passionate users. Companies like Stripe and Zoom are unstoppable because of it. Business chat apps like HipChat and Campfire stood no chance against Slack. I don’t even remember the names of the businesses Zoom bulldozed. Webex meeting, maybe?
The necessity of making a great app applies to us as well. Every day we write code, design and redesign the UI. We try to figure out which features work and which ones just don’t. But we don’t know yet if our app will turn out good enough. Sometimes you swing and you miss. Occasionally you can pivot an app and turn it into something great, but that’s the exception to the rule. If reception to your app is lackluster it means your app is bad and you should go back to the drawing board. It could happen to us. Fingers crossed.
[1] To be clear, every business needs to do marketing. My point isn’t that marketing is unnecessary, but that it’s not wise to compensate for bad product/market fit by doubling down on marketing.
Any time you try something new you don’t know how it will turn out. And your first attempt at anything won’t be very good. You don’t have to feel bad about this. It’s just how it is. If you know in advance that something will turn out great you’re probably working on something too easy.
With the knowledge that it’s counterproductive to pursue quality prematurely, you are now free to focus on something else: discovery. Be curious. Be open minded. Build something wacky. Experiment freely.
If all good design is redesign and all good work is rework then you have already decided you’re going to throw your prototypes out. This means you don’t need to worry about having to scale to a million users. You don’t have to worry about having “the best” architecture. You don’t have to worry about every pixel being in the perfect place. Take shortcuts. Stub out what you can. Copy-paste freely. It doesn’t matter.
You’re free. You’re free to work directly on your core innovation. That thing that makes your app interesting and unique. The less code you have the easier it is to move things around, delete, and rewrite. It’s at this time that you can hone in on what works and learn what doesn’t. It’s this phase of experimentation that will determine whether you’ll have mediocre or exceptional product/market fit down the road.
Spending extra time in this exploratory phase doesn’t guarantee you’ll get a good outcome, but it helps for sure. Knowing it’s futile to pursue perfection in means you can take ugly shortcuts with a clean conscience.
Of course, in the long term you do want quality. Of course you want to make a product you can be proud of. But in order to get there you’ll need to experiment.
That’s where we’re at for the time being. We want to figure out what works. We have a couple of ideas that we want to explore. Does it make sense to use a text editor for everything? Do we want our app to be offline-first and collaborative at the same time? Are we on the right track? I don’t know. Nobody knows.
We build and throw away. Build some more and throw away. With our 80 day deadline inching closer it’s difficult to resist the temptation to rush forward. To start building the app for real. But we can’t. Not yet. First we prototype. Then we build the MVP. Then hopefully we’ll end up with an MVP that sparks joy.
As a kid I would always work on one project or another, but I would often postpone working on the hard bit. I would the easy and fun stuff first, and it felt like making great progress. If I wanted to make a video game I would start with the game engine and interface but never get around to making the actual game mechanics or levels. If I wanted to make a web app I would try five different tech stacks in order to find the “best” one. I would build user registration and password reset systems but ignore the core functionality. By the time I got to the important part I would figure out that either the concept didn’t work or that I wasn’t able to build it. Abandon project. Repeat.
It took me an embarrassingly long time to learn but eventually the lesson stuck. Build. The. Hard. Part. First. No exceptions. In other contexts this is known as “unknown unknowns“, a concept popularized by Donald Rumsfeld. Your first priority is to work on the hard parts where you don’t know what kind of problems you’ll encounter (unknown) and you don’t know what it will take to address them (unknown). Then focus on the known unknowns. Save the rest for last.
We’re making a prosumer web app. For apps like these there are two types of hard problems: technical and user experience.
Tech challenges
Challenges are technically hard when you’re not sure if you can make something work at all, or work reliably, or fast enough. Or when you have no idea how long it will take.
For these technical challenges you want to build small prototypes. If you can figure out in a short time (days, a week) what it will take to find a good solution you want to do this early on. Way early.
We’re already making tech prototypes and we haven’t even figured out yet what the core functionality of our app will be. This might strike you as backward, but it’s entirely intentional. You can’t decide what the app should be like if you don’t know what you can realistically build in the time you have.
You can never build the ultimate version of your app. That would take years. If you’re lucky you can make 5%. And your app, despite being only 5% of what you want it to be, should still provide real value to the user and present a clear vision of where it’s headed. Technical prototypes help you figure out what has to get left on the cutting board. Tech prototypes turn unknown unknowns into known unknowns.
UX challenges
It’s easy to imagine better products. We all get annoyed with apps that don’t work right. Or are slow. Or that don’t have features we consider essential. Actually making an app that is great? Not that easy. It’s a cliché but true: everything is a trade-off. Fixing bugs and making software fast takes time that could otherwise be invested in features. It’s still true when you don’t take time into consideration because you can’t make software better by just piling on more features.
That’s the real difficulty of User Interaction (UX) design. If you want to make software that is intuitive to use you can only put a handful of features front-and-center. You can hide some extra functionality in panels or settings pages, but that doesn’t change the fact that you have to direct the user’s attention somewhere. If you put the right features front and center that will make your app cohesive and intuitive, and if you get it wrong your app will be mediocre at best. UX problems are known unknowns. You know you have to solve them and they won’t blindside you like technical issues do.
UI sketches and thinking will get you only so far. At some point you have to build a primitive version of your app to figure out if the concept works at all. Innovation is great, but you don’t want to be different for the sake of being different. You want to make something that’s original and also — at least for some people — much better than anything else out there. The sooner you know if you’re on the right track the better. The only good design is redesign[1].
Leave the easy parts for last
When the core of your app is done and you’re happy with it you can go back and work on the long tail of easy parts, the known knowns. By this time you should be super excited that your app is finally coming together and you’ll have no difficulty hammering out mundane stuff like billing, user registration, and a settings page.
Conclusion
Build small prototypes before committing to a specific vision. Make something you can interact with so you can feel if you’re on the right track.
Finally, keep an open mind. It’s possible (perhaps even likely) that your original approach is just worse. Sometimes you can pivot into something that works. In most cases you have to face reality and cut your losses altogether. It’s rough to abandon what you worked on for months or a year but it’s the price you pay for trying to innovate.
[1] These UX challenges apply mostly to consumer products. For B2B software customers are willing to put up with a broken and poorly designed app if it addresses a big pain point for them or makes them money. The quality bar for consumer apps is a lot higher.
@wcools
