I saw these tweets from Roy a few weeks ago…
Adding features so rarely adds.
— Roy Bahat (@roybahat)March 6, 2014
@kylec The thing people forget is removing is way more work than adding. Wish more teams had an anti-roadmap of things they plan to remove.
— Roy Bahat (@roybahat)March 6, 2014
…and i nodded - a lot.
To take it a step further, proactively creating an ‘Anti-Roadmap’ is a really great, super strong and opinionated way to deal with one of the biggest problems in early product design - feature creep.
It got me thinking about how I make decisions about Quibb - specifically what needs to be included, and how I handle feedback from (really smart, waaaaay more experienced than me) people that use Quibb. It also reminded me of a recent conversation with another founder, and how they’ve thought about and learned from adding features to their products.
Product Category Norms
My process for developing the very first version of Quibb was based on my belief in adhering strictly to what the current standard feature-set is for your category of products. Since Quibb is a social product built on content, this meant:
- Profiles (that you could follow)
- A feed of content
- The ability to put content into the product
- Social feedback to contributors
…done! Feature complete.
Thinking about your product based on what already exists in your category is a simple way to immediately nix features that don’t already exist within your ‘product peers’. It tells you ‘Okay, I can stop now’ and nips feature creep early on. If you’re lucky, you can also look at what features were tried in your category that failed and (with added thought, of course) preemptively add them to your own Anti-Roadmap.
Now vs. Later Features
One of the qualities that I really like about the idea of an ‘Anti-Roadmap’ is that it makes it very difficult to waste time and resources on features that - while they might make sense atm - you won’t need later on, and vice versa.
One of the most common requests I get for features on Quibb is a way to present a previously shared link to a member when they’re about to post that same link, and prompt them to ‘like’ the existing link vs. re-sharing it themselves. Yes, that makes a lot of sense… but only at this point in time, when the product is in its current state and at its current size. In the future (when many more professionals are using Quibb), each individual member needs to have the ability to share and get feedback on each piece of content that they put into the product. It wouldn’t make sense to drive everyone to one piece of content - Imagine if all of the Oculus acquisition tweets sharing Mark Zuckerberg’s post were all one… not the experience Twitter users want.
This ‘Hey member, that was already shared - like it!’ feature has landed on my Anti-Roadmap. I do think there are ways the product can manage this problem (e.g. Facebook has dealt with it well with their ‘smart feed’ and aggregation of similar content):

…but I doubt the best solution will be ‘That content was already shared by Person XYZ - vote on it!’.
Don’t Make the Same Mistake Twice
I recently chatted with a friend who’s been working on a very particular vision for the past 2y. They’re now building their 3rd mobile app related to this vision - not because the other two apps didn’t work (they have 5M and 7M users, respectively) - but because both of those products ending up drifting away from the vision and they weren’t interesting in working on them. Now they’re re-booting the product again, aiming hard to nail their vision.
When you put things on an Anti-Roadmap, it makes it very hard to accidentally-sorta-kinda build them. Based on their experience, this friend now knows what features won’t push the product to that vision. They can make really crisp decisions around what not to do, and make sure that they’re not potentially ‘leaking’ into a feature that will again propel them to a product they’re not passionate about.
————
The problem of ‘feature creep’ is one that’s dealt with on the daily by both early-stage founders and PMs. It’s also a term that team members don’t like to hear, as it can feel like an excuse to not dig into the amazingness of a really interesting, fun new feature. Deal with these inevitable problem upfront and save yourself a ton of time, energy, and resources - an Anti-Roadmap is a great place to start.
arunbeysi likes this
ahref likes this
traackr-people reblogged this from sandimac
nyctype likes this
roybahat likes this
clarityofthemind likes this
sandimac posted this