Ask HN: How to Write a Product Spec?
I've heard Michael Seibel say this multiple times. Write down your product spec when making an MVP and when iterating on it with a team too.
Can anyone here help with some examples please? Thanks!
Basically write two versions, one from a user perspective, i.e. what problem does it address and how does it solve it; the other from an implementation perspective, i.e. diagramming the major blocks and how they communicate with one another. Ideally, all of these being referenced back to the user perspective.
Finally, I find it useful to write a marketing plan, one that identifies the target demographic, their attributes and a SWOT / competitive products / markets analysis.
Sometimes I feel that I am a hybrid of a technical writer and devil's advocate to my clients.
If you're writing for engineers, it's still similar - what is the problem and how does this solve it?
I've done a few startups, and so far we've never really needed a technical product spec to hit project market fit. Partly because it's usually far better than the competition, e.g. a native app with lots of features vs a static competitor app built in phonegap.
Partly because it's intuitive but hard to put into words. We had a health recipe app. One of the most used features was a BMI calculator. I couldn't explain why we needed it, but it was half an hour to build (with unit tests!) and a chat with one customer said she had our app and the competitor's app because the competitor app had a BMI calculator. It would literally take less time to build it than write a spec for it.
The other questionable feature was a dodgy in app chat. It wasn't live, more like a single thread message board. Customers loved it and it provided most of our feedback. We ended up branching some WhatsApp groups from it instead of building a full thing. Part of the reason is that people use a healthy recipe app to commit to losing weight, and they wanted some company. Especially those who had unsupportive husbands and family. Or those who didn't know where to start.
So to reinforce, you have an idea of what the problem is, and what it looks like when it's solved. You should also have a feedback funnel early on to see how you're doing, though this more face to face with customers rather than an engineering thing.
Seriously though check out Shape Up: basecamp.com/shapeup
It’s a whole book on how 37signals makes the sausage. Goes over how they spec out a feature, decide on what should be built, etc. They’re a team so not everything applies to individuals but there’s a lot of useful ideas. They give concrete examples and case studies. Including specific examples of specs.