Book review: “Inspired: How To Create Tech Products Customers Love”

Fig. 1 — “Root Causes of Failed Product Efforts” by Marty Cagan — Taken from: https://www.mihneadb.net/notes-on-craft-conf-2015/
  1. Stakeholder-driven products: It’s a top down approach which leads to stakeholder-driven products and teams that don’t feel empowered
  2. Business cases are mostly fictitious: I couldn’t agree more with Cagan when he argues that the two main business case inputs — how much money we’ll make and how much it will cost — are complete unknowns. We can’t know how much money we’ll make because that depends entirely on how good the solution turns out to be. In contrast, a lot of products end up making no money whatsoever! One of the most critical lessons in product, Cagan explains, is “knowing what we can’t know.”
  3. Product roadmaps — There are two problems with traditional, feature led product roadmaps. Firstly, the reality is that half of our product ideas are simply not going to work. I always cringe when I see product roadmaps that contain detailed features prioritised prioritised for an entire year … In my experience, until you start discovering, implementing and launching product ideas, you’re not going to know whether your product is actually going to work. Secondly, even when ideas do prove to have potential they’re likely to need several iterations to reach the point where they deliver tangible business value. Cagan introduces the term “time to money” to refer this evolutionary process.
  4. It’s not about gathering requirements for engineers to implement — I recently came across an organisation where they employed an entire team of project managers and business analysts whose main job it was to gather stakeholder requirements, and document them for designers and engineers to implement. Cagan rightly makes the point that “this is 180 degrees away from the reality of modern tech product management.”
  5. UX designers are getting involved way too late — Don’t involve designers only once the requirements have been gathered, it’s simply too late as the designer won’t be able to add much value add this stage.
  6. Engineers are getting involved way too late — If you’re just using your engineers to code, you’re only getting about half their value. I love the ‘little secret’ that Cagan shares with us: “engineers are typically the best single source of innovation.” He’s totally right!
  7. Agile for delivery only — Cagan talks about “Agile for delivery”, whereby product development teams work in an Agile fashion, but the rest of the organisation isn’t.
  8. Project-centric processes — The company usually funds projects, pushes projects through the organisation, and finally launches projects. Unfortunately, projects are output and product is all about outcome. I’d add that most projects are one-off pieces of works whereas products have a continuous lifecycle, until the product is being discontinued.
  9. Customer validation happens way too late — Cagan points out the biggest shortcoming of the old waterfall process, which is that all the risk is concentrated right at the end and that customer validation happens way too late. Instead, customer validation or discovery should be continuous and needs to happen early and often.
  1. Risks are tackled upfront, instead of at the end
  2. Products are defined and designed collaboratively, rather than sequentially
  3. Finally, it’s all about solving problems, not implementing features
Fig. 3 — Continuous Discovery and Delivery — Taken from: Marty Cagan, Process vs Model, https://svpg.com/process-vs-model/, 7 August 2017
  1. Will the user buy this (or choose to use this)?
  2. Can the user figure out how to use this?
  3. Can our engineer build this?
  4. Can our stakeholders support this?
  1. The product vision and strategy
  2. The business objectives
  • Financial risk — Can we afford this solution?
  • Business development risk — Does this solution work for our partners?
  • Marketing risk — Is this solution consistent with our brand?
  • Sales risk — Is this solution something our sales staff is equipped to sell?
  • Legal risk — Is this something we can do from a legal or compliance perspective?
  • Ethical risk — Is this solution something we should do?
  1. Objective — What business objective is this work intended to address?
  2. Key results — How will you know if you’ve succeeded?
  3. Customer problem — What problem will this solve for our customers?
  4. Target market — What type of customer are we focused on?
Fig. 4 — Ash Maurya’s “Lean Canvas” — Taken from Ash Maurya, “Running Lean”
Fig. 5 — Buffer example of a ‘smoke and mirrors’ landing page — Taken from: Christopher Bank, 15 ways to test your minimum viable product, https://thenextweb.com/dd/2014/11/12/15-ways-test-minimum-viable-product/, 12 November 2014

--

--

--

Product at Intercom, author of "My Product Management Toolkit" and “Managing Product = Managing Tension” — see https://bit.ly/3gH2dOD.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How to improve iOS Alarm

Week 3 (8th-13th June)

What You Can Do Right Now to Be Human-Centered

5 Things to Examine Closely When Looking to Hire a 3D Animation Studio

8 Onboarding Design Tips  to Make Your Product a Total CRUSH for Users

My First Digital Sprint- Part One!

Building a UX design team for the metaverse at ZED RUN

Rewind and Restart

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
MAA1

MAA1

Product at Intercom, author of "My Product Management Toolkit" and “Managing Product = Managing Tension” — see https://bit.ly/3gH2dOD.

More from Medium

🕊 Using Customer Feedback for Product Innovation: the Nivea Case

From Startup to Scaleup: Lessons Learned From Scaling A B2C Product in Southeast Asia

Product too has a Life… (cycle)

Clearing the Confusion Around Product Ops