Intercom has been formatting some of its “wisdom” into “books”. They’re all no-cost but they want you added to their email list.
A friend of mine recently broadcasted how much they loved the Product Management book, and how it’s their favorite solid, concise, outline of online software product management, even though they don’t really like Intercom as a product
I skimmed it, and I think it looks pretty solid. I put it on my list to read closely.
If anyone else is into this kind of thing, this thread can be a mini book club for it.
Adam pointed out this paragraph which I’m allllllll about:
4. BUT WE CAN JUST MAKE IT OPTIONAL
This leads to death by preferences. Making features optional hides the complexity from the default screens in the interface, but it still surfaces everywhere else. The visible cost of this is a messy interface with lots of conditional design and heaps of configuration. The hidden cost is that every optional feature weakens your product definition. You become “a time tracker that can also send invoices and, sorta, do payment reconciliation. But not reporting. Yet…I think…I don’t know.”
(I guess I should hurry and write my anti-settings principle blog post [EDIT: done!] before it’s completely common knowledge!)
Ok, I read the first chapter of it and am now less interested in reading along. I think I’m not sure I see the point of trying to cause the usage of different parts of the product to be even. Like, obviously people are going to use “data entry” far more than any other feature of Beeminder. And that is as it should be.
I suppose maybe we don’t have different “features” in the same way that they are thinking of features?
I made it to the end of the book. God I love Beeminder so much!
Here are my notes:
There are no small changes. Everything affects everything else, including documentation and support. The work involved in actually changing the code is the tip of the iceberg.
Getting some functionality for free is like getting a free pet, ie, expensive.
Beware the fre-cently bias (overweighting things you hear frequently or heard recently). I.e., discount the whims of a small sample of vocal users.
(Plenty of obvious things like not doing trendy shit.)
Sprinkle some Quick Wins in your roadmap so there are never long periods where customers feel the application has been abandoned. (Could call it the Anti-Cobweb Principle? See Trevor Blackwell’s footnote in our UVI blog post. This is a way bigger deal than people appreciate, in my opinion.)
They make a pretty good, if self-serving, argument for in-app messaging – the time when users care about new features and tips and such is when they’re using your app.
Don’t be afraid to say no to feature requests or even to kill existing features.
There’s obviously more than that in the 60-page book but I think a lot of it was not advice I needed (or needed so badly that I didn’t recognize it?). So, if you’re sufficiently like me, then hopefully I have saved you a lot of time by distilling the book into those 7 points!