Product development rules of thumb I picked up over the years β are they still on the money or out-of-date? Ties in w/ other areas (marketing, design, etc), as product is not a silo!
- π
ββοΈ Don't give customers a reason to say "no". Eliminate detractors. Give the customer every reason to try your product...
- πͺ₯ The Toothbrush Test β is the product used as often as a toothbrush? Google popularised this test... (https://www.businessinsider.com/larry-page-toothbrush-test-google-acquisitions-2014-8)
- π‘ Is your idea popular, urgent and/or frequent? If the Toothbrush Test emphasises frequency, then Kevin Hale's "How To Evaluate Startup Ideas" looks at whether there's a market and how desperate the customer is (https://www.ycombinator.com/library/6e-how-to-evaluate-startup-ideas)
- π A good market is where (a) there's reach / many potential customers, (b) they have purchasing power, (c) high motivation / want their life to change. Jobs To Be Done isn't a formula but a framework to understand this. https://justinjackson.ca/build
- π₯ Audience-first. As a product person or engineer, you might forget how much market matters in Product-Market-Fit (I'm certainly guilty of this). (https://betterprogramming.pub/finding-an-audience-for-your-side-business-66ecd59d9c9c
- π
The CRAP rule β Contrast, Repetition, Alignment and Proximity from Robin William's Non-Designer's Design Book. If you work in product design/front-end dev, you probably already practise this. If you don't, it's a cheatsheet for making sure your product doesn't look crap. π
- π₯ Create your own category. Law #2 of The 22 Immutable Laws of Marketing by Ries, Trout. If the first step is for your customer to articulate what you do, being their #1 in a category is the north star (https://www.amazon.co.uk/22-Immutable-Laws-Marketing/dp/1861976100)
- π Network Effects β the more scientific discussion around "sticky" user behaviour (https://www.nfx.com/post/network-effects-manual/)
- βΌ Build-Measure-Learn. Eric Ries's basic but effective scientific approach towards product development still holds today IMO. You should invalidate ideas, not validate them, that is the basis of the Scientific Method (https://en.wikipedia.org/wiki/Scientific_method)
- πββοΈ Always optimise for speed and limit scope early on IMO. If the levers for shipping product are quality, speed, scope, definitely reduce scope and speed up your learnings (https://blog.mariohayashi.com/delivering-software-product-management-triangle)
Original tweet here! But I've summarised them here for convenience... would love to know if there any big ones left off the list/you think any are outdated/irrelevant