Downfall of a once readable blog post
07 Apr 2014
DIARY, 12TH APR 2014
I absolutely blitzed through v0.1 of my ultra-minimal to-do app this weekend. It was the first project where I’ve really fixated on building the features that enabled me to actually use the app ASAP. The difference this focus made was unbelievable. I’ve summarised my astonishment in a nice, pithy blog post, and I’m really looking forward to publishing it and seeing what the internet makes of it.
1ST DRAFT, 12TH APR 2014
How to decide what feature to build next
None of the billions of to-do apps out there are quite minimalist enough for me. So like any good programmer with a spare rainy weekend, I decided to hack together my own. The project has been going incredibly quickly since I started actually and religiously following one simple rule:
“The only features you should build are those that are literally causing you physical pain or preventing you from using your app.”
This principle helped me get to a genuinely usable app that was actually giving me value after a single day of work. It suddenly became incredibly simple to see what the next thing I should build is, and for an entirely personal project like mine, you don’t even need to do any formal user-testing or data interpretation. Is this feature going to help you right now, or is it just a might-be-cool-one-day? Is your app more useful to you than it was before your git push heroku master, or is it just flabbier and more confusing? Are you having a better time whilst in your app? If no, sort it out.
DIARY, 1ST JUL 2014
Found a draft blog post I threw together in April about how to choose what to build next. It felt pretty revolutionary at the time, but now just seems basic and obvious. On the other hand, I haven’t published anything for a while, so I’ll add in some more cool stuff about how I’ve started using Omnifocus to batch making feature decisions and then just put it out there and see what people make of it.
DIARY, 5TH JUL 2014
Was about to publish “How to decide what feature to build next”, but then realised that I don’t properly acknowledge the fact that things aren’t so simple if you’re building something that you want to be used by people other than yourself. I don’t want to get torn to shreds on Hacker News for not being aware that most developers don’t have the decadent luxury of building purely for themselves. I’ll make it clear that I know this, explain how my thing still kind of applies in this situation, and then push the post out the door for the world to see.
DIARY, 6TH JUL 2014
A little concerned that my post looks like I think I’ve got everything solved and am a total product genius. I think I probably know more than a lot of people, but there’s so many others who’ve achieved and written so much more than me. I’ll just sprinkle in some caveats and humbleness, then publish, get some feedback and iterate on it.
DIARY, 2ND AUG 2014
Back from the European Bruce Springsteen Convention. Sadly The Boss did not turn up, but we’re hopeful that he’ll make it to the Christmas party. Time to actually finish the blog post I started before I left. The content isn’t as weighty or timeless as I would like, and I think it’s stylistically a bit too dry and bland. I’ll throw in some of my trademark anarchic humour to spice it up a little, but I still can’t imagine Steve Blank putting it on his must-read list of startup essays. It’s too specific to one situation; I’ll expand its horizons and add in an outline of the universal framework for approaching product decisions that I’ve been thinking about (the Feature Essentiality Scale (FES)). Then BOOM, get it in front of real readers ASAP and see what they make of it.
DIARY, 7TH AUG 2014
Not convinced by the stuff about Omnifocus anymore, I’ll take most of it out. Am now slightly concerned that the post is now a little too universal. It’s not clear how to use its lessons in your day-to-day life. I’ll round it off by coming back to earth with some concrete examples, then it’s going live!
FINAL DRAFT, 7TH AUG 2014
Introducing the Feature Essentiality Scale (FES)
None of the billions of to-do apps out there are quite minimalist enough for me, although many are still very popular. So like any programmer with a spare rainy weekend, I decided to hack together my own. The project feels like it has been going less slowly than usual since I started actually and religiously following this one simple rule, although it might just be coincidence:
“The only features you should build are those that are literally causing you physical pain or preventing you from using your app.”
This principle helped me get to a genuinely usable app that was actually giving me value after a single day of work, although the code is not as good as it should be. It suddenly became a bit simpler to see what the next thing I should build is, like solving a maths problem that could also be solved by a gorilla that isn’t even particularly smart by gorilla standards. Note that I am aware that unless you are building literally just for yourself, it’s stupid for you to be your only test subject.
It’s also crucial to remember that batching things is important because it helps you save time by not constantly context switching. You should read “Getting Things Done” by David Allen for more on this topic if you haven’t already, otherwise you are even stupider than the, to put it kindly, non-Einsteinian gorilla I have already made reference to in the previous paragraph.
All features in all products fall into one of 3 categories on the Feature Essentiality Scale (FES):
- Completely essential
- A bit essential
- Not at all essential
Once you view product development through the lens of the FES, everything becomes incredibly simple, to the point where any gorilla of even moderate intelligence could understand it, which is good because many of the product managers I know are a lot like gorillas. A full discussion of this system and its ramifications would take a whole series of blog posts, but the most important and revolutionary thing to note is that if a feature isn’t “A bit essential” or “Not at all essential” then it must be “Completely essential”. This has a number of far-reaching consequences. For example, if you have a to-do app, you might be considering whether or not you need the ability to add a new to-do. Firstly, is this “Not at all essential”? Clearly not? Then is it “A bit essential”? Again, no. So, without even needing to ask whether it is “Completely essential”, we can immediately deduce that it is, and that our to-do app should allow users to add a new to-do.
You should ask yourself, is this feature going to help you right now, or is it just a might-be-cool-one-day? Is your app more useful to you than it was before your git push heroku master, or is it just flabbier and more confusing, like a fat gorilla in an episode of The Wire, a very serious and gritty show that typically does not contain any gorillas? Are you having a better time whilst in your app? If no, sort it out.
DIARY, 14TH OCT 2014
Sent that post I was working on to Barry and Paul for some feedback a week ago. Haven’t heard anything back, they’re probably really busy. But I’ve had another post about some of the deeper subtleties of the FES brewing inside me for a while now - I think it’s going to be a real winner.
DIARY, 12TH APR 2014
I absolutely blitzed through v0.1 of my ultra-minimal to-do app this weekend. It was the first project where I’ve really fixated on building the features that enabled me to actually use the app ASAP. The difference this focus made was unbelievable. I’ve summarised my astonishment in a nice, pithy blog post, and I’m really looking forward to publishing it and seeing what the internet makes of it.
1ST DRAFT, 12TH APR 2014
How to decide what feature to build next
None of the billions of to-do apps out there are quite minimalist enough for me. So like any good programmer with a spare rainy weekend, I decided to hack together my own. The project has been going incredibly quickly since I started actually and religiously following one simple rule:
“The only features you should build are those that are literally causing you physical pain or preventing you from using your app.”
This principle helped me get to a genuinely usable app that was actually giving me value after a single day of work. It suddenly became incredibly simple to see what the next thing I should build is, and for an entirely personal project like mine, you don’t even need to do any formal user-testing or data interpretation. Is this feature going to help you right now, or is it just a might-be-cool-one-day? Is your app more useful to you than it was before your git push heroku master, or is it just flabbier and more confusing? Are you having a better time whilst in your app? If no, sort it out.
DIARY, 1ST JUL 2014
Found a draft blog post I threw together in April about how to choose what to build next. It felt pretty revolutionary at the time, but now just seems basic and obvious. On the other hand, I haven’t published anything for a while, so I’ll add in some more cool stuff about how I’ve started using Omnifocus to batch making feature decisions and then just put it out there and see what people make of it.
DIARY, 5TH JUL 2014
Was about to publish “How to decide what feature to build next”, but then realised that I don’t properly acknowledge the fact that things aren’t so simple if you’re building something that you want to be used by people other than yourself. I don’t want to get torn to shreds on Hacker News for not being aware that most developers don’t have the decadent luxury of building purely for themselves. I’ll make it clear that I know this, explain how my thing still kind of applies in this situation, and then push the post out the door for the world to see.
DIARY, 6TH JUL 2014
A little concerned that my post looks like I think I’ve got everything solved and am a total product genius. I think I probably know more than a lot of people, but there’s so many others who’ve achieved and written so much more than me. I’ll just sprinkle in some caveats and humbleness, then publish, get some feedback and iterate on it.
DIARY, 2ND AUG 2014
Back from the European Bruce Springsteen Convention. Sadly The Boss did not turn up, but we’re hopeful that he’ll make it to the Christmas party. Time to actually finish the blog post I started before I left. The content isn’t as weighty or timeless as I would like, and I think it’s stylistically a bit too dry and bland. I’ll throw in some of my trademark anarchic humour to spice it up a little, but I still can’t imagine Steve Blank putting it on his must-read list of startup essays. It’s too specific to one situation; I’ll expand its horizons and add in an outline of the universal framework for approaching product decisions that I’ve been thinking about (the Feature Essentiality Scale (FES)). Then BOOM, get it in front of real readers ASAP and see what they make of it.
DIARY, 7TH AUG 2014
Not convinced by the stuff about Omnifocus anymore, I’ll take most of it out. Am now slightly concerned that the post is now a little too universal. It’s not clear how to use its lessons in your day-to-day life. I’ll round it off by coming back to earth with some concrete examples, then it’s going live!
FINAL DRAFT, 7TH AUG 2014
Introducing the Feature Essentiality Scale (FES)
None of the billions of to-do apps out there are quite minimalist enough for me, although many are still very popular. So like any programmer with a spare rainy weekend, I decided to hack together my own. The project feels like it has been going less slowly than usual since I started actually and religiously following this one simple rule, although it might just be coincidence:
“The only features you should build are those that are literally causing you physical pain or preventing you from using your app.”
This principle helped me get to a genuinely usable app that was actually giving me value after a single day of work, although the code is not as good as it should be. It suddenly became a bit simpler to see what the next thing I should build is, like solving a maths problem that could also be solved by a gorilla that isn’t even particularly smart by gorilla standards. Note that I am aware that unless you are building literally just for yourself, it’s stupid for you to be your only test subject.
It’s also crucial to remember that batching things is important because it helps you save time by not constantly context switching. You should read “Getting Things Done” by David Allen for more on this topic if you haven’t already, otherwise you are even stupider than the, to put it kindly, non-Einsteinian gorilla I have already made reference to in the previous paragraph.
All features in all products fall into one of 3 categories on the Feature Essentiality Scale (FES):
- Completely essential
- A bit essential
- Not at all essential
Once you view product development through the lens of the FES, everything becomes incredibly simple, to the point where any gorilla of even moderate intelligence could understand it, which is good because many of the product managers I know are a lot like gorillas. A full discussion of this system and its ramifications would take a whole series of blog posts, but the most important and revolutionary thing to note is that if a feature isn’t “A bit essential” or “Not at all essential” then it must be “Completely essential”. This has a number of far-reaching consequences. For example, if you have a to-do app, you might be considering whether or not you need the ability to add a new to-do. Firstly, is this “Not at all essential”? Clearly not? Then is it “A bit essential”? Again, no. So, without even needing to ask whether it is “Completely essential”, we can immediately deduce that it is, and that our to-do app should allow users to add a new to-do.
You should ask yourself, is this feature going to help you right now, or is it just a might-be-cool-one-day? Is your app more useful to you than it was before your git push heroku master, or is it just flabbier and more confusing, like a fat gorilla in an episode of The Wire, a very serious and gritty show that typically does not contain any gorillas? Are you having a better time whilst in your app? If no, sort it out.
DIARY, 14TH OCT 2014
Sent that post I was working on to Barry and Paul for some feedback a week ago. Haven’t heard anything back, they’re probably really busy. But I’ve had another post about some of the deeper subtleties of the FES brewing inside me for a while now - I think it’s going to be a real winner.