Running a #startup for the first time? Here’s a few bits of unsolicited advice from someone who’s been there a few times. Most of this is relevant to software development – there are some things that can be different working with hardware or other things with longer lead/iteration times.
1.) Secrecy doesn’t matter. Until your product is successful, it’s not worth it for anyone to care about it. If you’re pre-product/market fit, you shouldn’t hesitate to tell anyone you think can help you what your idea is. Don’t bother with NDAs. Don’t bother with patents. Nothing will protect you better than speed. Secrecy and speed work against each other.
2.) Don’t worry about competitors. You may hear of someone doing something that on paper sounds exactly like what you’re doing. That’s fine. It’s easy to get scared off of a concept when this happens, because you’re worried about losing first-mover advantage. But in most things, first-mover advantage doesn’t actually exist. And literally everything I’ve ever worked on – someone’s out there trying to do something similar. But it’s never *the same*, because no one has the experience and perspective that you do, so if you’re trying to solve someone’s problem, you’ll do it in a different way than anyone else. And those differences are what will differentiate your product, not the high-level thing that your product is doing. So if you’re working on a tool that auto-annotates meetings and follows up with important tasks, and you hear someone else working on something that sounds similar – don’t sweat it. Your products will almost certainly be totally different, and prioritize different things.
3.) No, really – don’t worry about competitors. Early on, some folks do a lot of “competitive research” to figure out the features your product needs to have before launch. If you’re doing this, you’ve already lost, because you’ll always be months, if not years behind the competition. All you need to do is focus on the problem you are trying to solve for a particular audience, and understand what that specific, small audience needs to have a great experience. Stuff that already exists that you can see in your competitors’ products? They’re basically “solved problems”. If you’re building something new, you have “unsolved problems” that you absolutely need to address first.
4.) This is the tough one, because very few people know how to do it correctly. But prototype fast, and test with real users as soon as you humanly can. And I don’t mean “build a shitty version of your thing” or “build something janky and busted that doesn’t do the right thing.” Building a honest-to-goodness minimum viable product that will *answer the questions you need answered* about whether you’re building something someone desperately needs – that’s a very tough challenge, and it’s *very* specific to your product, what you know about your audience, and what you don’t. There is no boilerplate answer for “what features are necessary for an MVP” that you can steal from someone who’s done this before. It requires deeply understanding your potential audience, and deeply understanding what you’re trying to do, and then finding out what you don’t know in order of “biggest risk” on down.
In addition to the base complexity of trying to understand what a real MVP should contain, you’re also fighting everyone’s existing process, training, and how they evaluate whether something is “good” or not. By most metrics, MVPs will be “bad” products. They shouldn’t be robust. They shouldn’t be pretty. They shouldn’t scale. (Of course, those statements can be wrong if your product specifically is focused on one of those areas, and for some reason that’s the thing you need to get answers about.)
Great artists are great because they make great art. Great engineers are great because they write great code. By whatever definition great is in your field. But a great MVP is evaluated by if you’re getting great, actionable, understandable *information* from your target audience. The information doesn’t even need to be *positive* for your MVP to be doing a great job. If you are learning things you didn’t know before, and couldn’t have known before, then your MVP is doing a great job!
It’s a way of thinking of greatness that is surprisingly counterintuitive, because you will feel bad about showing it to people (because it’s not “great work” by a traditional definition) and you will often feel bad about the data you get back (which is that your first iterations of your MVP are showing that users are NOT responding to your product the way you thought they would).
But imagine if you’d spent three years working on that product, and *then* users didn’t respond the way you thought they would. Then your company would be dead. So if you’re learning, and creating actionable data, and gaining a better understanding of your audience and product, the MVP is doing its job.
Learning fast is 100% of a startup’s job in the early days. Every decision you make as a #leader should be geared toward maximizing how fast you can learn. Usually that means maximizing iteration speed and minimizing risk (which can mean building infrastructure that doesn’t feel like “product” at first!), so that you can learn quickly.
If you’re doing this for the first time, and this all sounds wrong to you, DM me. Let’s talk. Because *so* many startups make the same mistakes – they keep things under wraps. They spend years building before showing anything to anyone. They trust their own judgment and insight. And then they launch and are dead in months.
There is no more expensive and wasteful mistake than building the wrong thing. Learning fast with real users is the absolute best way to make sure that doesn’t happen. It may be the only way.