The Adventures Of A Bad Startup #3: Tales Of The Feature Creepshow
An incredible dive in the magical universe of a startup that methodically failed everything, narrated by its desperate founder which is doing the V2 and won’t let go, you hear me?
This week, if you didn’t get my lousy pun, we’re going to talk about something called Feature Creep — or Feature Creeping.
“ But what’s Feature Creep, uncle?” asks my sweet 7 years old niece while reading these lines — she wants to fail a startup too.
When you start a project, during the prototyping phase, you often list the elements your project is going to need. A connection module, a client back-office, an image gallery, etc. The risk is not being able to stop. Because you want to do better, add this little important detail, and so on. You end up with something much bigger than you initially envisioned, making the project unrealistic in the time & budget you have.
That’s Feature Creeping, kiddo.
Feature Creeping is dangerous because it’s insidious. You feel like you have planned something simple, but, slowly, without really thinking about it, you added bits and pieces, and didn’t realized you lost control.
Note that this does apply to other jobs as well. It can happen during the fiscal constitution of a company, while building a specialized team dedicated to a project, even in a cooking recipe (“aaand maybe some tarragon too”)
Even while writing a post like this one, I could be tempted to cover everything at once, and BAM: unreadable wall of text.
Ok, now that you get the mental process: this is not unavoidable. You can protect yourself from the dangers of excessive complexity, for example using the Lean Design principles, as brilliantly outlined in the book Lean Startup by Eric Ries, that you should definitely read if you haven’t already — but I know you have, come on.
Alas! Sometimes even those precautions are not enough. We’re here to learn how to properly fail a startup, so i’m gonna start with a practical example. Let me explain how, being fully aware of all this, we still managed to build a giant, incredibly complicated turd. First, I need to tell you more about the first version of Castr.
Case Study
Our project was to deliver geo-localized information, in real-time. Standard use: you’re at home, hear noise in your neighborhood, want to know what’s happening. You start the app and see posts made by users from your area (it was a brawl at a bar nearby). On the other side of the event: You’re in the street, see a fight in front of a bar, snap a pic, post it on Castr, and people chilling at home can see and comment the information.
Basically, all we need is a wall and a posting system. Simple enough.
Now of course if you live in some remote place in the midwest… nothing is happening. Lame. So we’re going to add a feature that allows you to follow people, wherever they are. Let’s split the main wall into “Here” and “Friends”. BAM? Still simple enough.
Yeah but wait: Castr is about knowing what’s going on at a specific place, not what’s happening to some people, right? You need some way to follow places, so you’ll be able to get info before you know people being there, right? Or you could have a map you would use to know about any random position? Alright, this is just 3 features, we can do it. Go.
Oh, and we need users to do more than comment on posts. Maybe they could vote? So that we’d be able to sort what’s useful from the rest? And some kind of retweet (‘recast’) to transmit an info to the next user? And don’t forget the usual profile pages — people & places, authentication system, settings, some details…
“What the fuck? How did we end up here? Let’s trash everything and start over” — Said no one ever.
On the contrary, I was rather proud of the project’s simplicity. And we had some valid points: after all, the whole thing was pretty coherent. What the user could do was logical compared to what we expected from the service, the app’s architecture was intuitive, and moreover, we had indeed removed a ton of things for the MVP:
- Video support
- Private messaging between users
- The huge desktop version that would have made us do everything twice
- Real-time post displaying
- Dynamic transactional e-mailing (“This week on your network”)
- Places recommandations
- Loaaaaads of other things.
From the inside, it actually looked small, compact… simple.
A year and a half later
Haha, this is so funny *chokes back tears*, it should have been “three months later”, but we losers took a whole eighteen months to realize the mistake, hahaha.
So, a year and a half later, we were ready to launch. This is May, 2015.
In hindsight, we weren’t ready at all. I saw somewhere a figure that showed rather well the feeling of having something pretty finalized when it’s actually not. It looked like this — thanks to the anonymous that initially did it:
You guessed it, we launched Castr thinking it was a good product. Had we stepped back a bit to look at the big picture, we would have seen it still needed a lot of polishing. This was because of the Feature Creep. Less things in the product from the start would have meant less things to polish in the end. But the mistake was done and we had to move forward anyway.
The rest is terribly common. We launched, and no one used the app.
To be fair, the feature creeping is not the only one to blame — far from it — and I will talk about other reasons later. At that time we were stuck with some major issues:
1 — The app was too complex to handle
2 — It was badly finished
3 — It costed a fortune to maintain
Why it’s better now (no, really)
Now that we failed so miserably, I finally understand what MVP means — you know, Minimum Viable Product. It’s not an acronym. It’s a list.
- Minimum: Remove EVERYTHING that is not absolutely necessary. Ask yourself if even the most basic features are useful: “Do we really need to be able to login?”. If you compromise, you failed.
- Viable: It needs to work as is. If your product is pretty and functional but bug-ridden, and will explode in the hands of the first user, or at the first connection peak, it’s not viable, you failed.
- Product: don’t ever forget your users want a finished product, not a demonstrator or a prototype. If you launch, but you know, deep down, that your product needs at least one or two majors features to be really useful, you failed.
Do better, do less
So after failing Castr 1, we thought: what do we really want to do? What problem are we really trying to solve? And the answer was: we want to connect nearby people. That’s it. Not one by one like WeChat or Tinder would do, like a “neighborhood chatroom”. Keep it simple, stupid.
Castr 2 is that, and only that. A chatroom, dynamically generated by taking people that are close. You start the app and talk with nearby people. No more.
From there, the app’s architecture is very straightforward. A profile page, a chatroom page, a message page.
To avoid feature creeping, the trick was to list the anti-features: the things we don’t actually need.
- Login? No need, we generated random usernames at startup
- Comments? No need, people don’t submit posts, but messages. A comment is just another message.
- Places? No need to list places anymore (restaurants, bars, airports, etc that need a reverse geo-coding insfrastructure.), the user just talks to other users close to him.
- Public profile? No need — at first.
- Website? No need, Castr 2 is fully nomad, no point to have a desktop version.
You get the logic.
So: Minimum — No unneeded features, Viable — It’s already 100% stable and runs very well, Product — You can chat with nearby users, it works flawlessly (and it’s already very fun on beta versions).
But this time, we won’t do the same mistake twice. We take our time to polish the app until it’s near perfect, so that at launch we’ll have something we really like, something we’ll be proud of, and not the kind of crap that gets instantly shot down by a “hey, this piece of shit doesn’t work”, shattering your ego in the process.
Ah, important note: in our case like in every other, this whole MVP thing is not about creating a super-simple product and then stopping there. It’s about launching a simple product, quickly, allowing you to know if people are interested in it (it’s called Market Fit, more on that later). Then, you’ll have time to build on it, progressively, and put everything you want to. Or stop before losing a decade of your life.
Ok, I know, this seems obvious. Like when you watch Ninja Warrior and you’re like “oh come on, it’s not that hard”. But believe me, from the inside, it’s easy to miss the pitfalls — or fall in the pits, whatever.
What did you learn today, little niece?
Feature Creep is dangerous. You don’t see it coming, and it can badly screw with your planning, just because you added a few useless-but-cool things in your project. The solution is to focus on a Minimum Viable Product and have a hard look at each feature to determine if it’s really, truly necessary.
It’s also exponential. Each addition to a project affects the whole of it. A feature has to be tried and tested for itself, in addition to the others, and as something that affects the project globally — sometimes deeply. Take cascading effects into account.
Finally, Feature Creeping is dangerous in itself but also in the sense that it’s diverting, meaning it can blind you from the fact that your project is fundamentally too complex — not the addition of features, the basic concept. Simplifying something already too complex gives you the illusion of being lean when in fact you’re working of a giant piece of shit.
That’s it. A bit more technical than last week but it needed to be done. I’ll talk about something lighter next week. In the meantime, time for art.
♩ ♫ Cultuuure corneeeer ♫ ♪
With a Creepshow pun as a title, I obviously thought I should make a piece about Stranger Things, the sweet new Netflix show, but everybody is already talking about it so let’s go for something different. And since the last two weeks have been about movies, let me show you some illustration this time, with a very creative artist in an already fertile discipline.
Simon Stålenhag is a Swedish painter/illustrator as well as a game developer and music composer. He paints sci-fi landscapes which are particularly interesting because they are mostly set in the banal reality of grey Nordic suburbs.
These kind of illustrations often feature very saturated and colorful futuristic elements on a pretty deep blue sky, or on the contrary amazingly dark and creepy ghettos perfectly suited if you need forbidden military prosthetics installed at the best price — or, you know, deathsticks.
And that’s why Simon Stålenhag is interesting: his work shows normal things, in normal places. It displays routine and reality. Sure, there’s a huge mecha in this field. But it’s a real field, with kids playing in it, a rusty cop car you could find in any European countryside, a grey sky you’d easily find today in Paris, or distant project buildings like in every suburb on earth.
His artworks are great (not even considering the awesome framing and composition) because they show science fiction the way it would be if it was here, now, in our very real world. If Toyota was releasing a new atomic flying Corolla tomorrow, we wouldn’t suddenly become muscular blockbuster heroes with sexy scars and tattoos. We’d still use it to go buy some toilet paper at Walmart on a rainy Tuesday morning.
But it would still be a bit cool.
(You can find more of Simon Stålenhag’s amazing work on his website and even buy some prints on Red Bubble. Do that, i’ve put some all around my flat, best investment ever.)
Cheers
Barth Picq
Hey don’t forget, this has been a bumpy road but we’re not dead yet. Get the latest info on social network or on the website. Here’s a link, free of charge, but full of French:
