‘Product Truths’: My First Review

- Ian Finn on Product Leadership-

Something small happened this week that mattered more to me than I expected: Product Truths, my first book, got its first review.

Five stars, from a reader who took the time to write something genuinely thoughtful rather than a one-line courtesy note. She called it "accessible and easy-to-read," and picked out something I truly cared about getting right - that customer understanding is a strategic asset, easily overlooked under pressure, even though it's the foundation for better decisions.

There's a particular kind of validation in a stranger reading your work and understanding exactly what you were trying to say. Not because I needed permission to believe the ideas were sound - but because writing them down and putting them into the world is a different kind of exposure than living them out in a career. You don't fully know if it lands until someone tells you it did.

One review doesn't make a book. But it's a good reminder of why I wrote it in the first place - not to add to the noise, but to write the thing I wish someone had handed me earlier in my own career - to help cut through it.

Onwards.


Product Truths: Five Principles for Building Products That Work at Scale eBook : Finn FCIM CMkr MIoD, Ian : Amazon.co.uk: Kindle Store

Eighteen years. Five principles. One book.

- Ian Finn on Product Leadership -

I'm genuinely excited to share that my first book, 'Product Truths: Five Principles for Building Products That Work at Scale', is now out in the world.

It distils eighteen years of product leadership learnings across a range of FTSE 100 companies, three Global 500 organisations, and three UK government departments into five principles for building products that survive contact with real-world complexity — not just the ones that look good in a deck.

Writing it required the same discipline I've used as a practitioner — finding the pattern under the noise, then simplifying until only the essential structure remains. Turning that lens on my own experience has been one of the most satisfying parts of it all.

One of the quotes that opens the book, from Lewis Hatchett, is the one that actually got me to start writing it in the first place:
"Make decisions your 8-year-old self would admire, and your 80-year-old self would be proud of."

It's not a bad test for a product decision either. Finishing this book certainly felt like one of mine.

📖 Available now everywhere — one link here:
https://books2read.com/producttruths

“𝐓𝐞𝐜𝐡 𝐝𝐞𝐛𝐭” 𝐢𝐬 𝐨𝐟𝐭𝐞𝐧 𝐭𝐫𝐞𝐚𝐭𝐞𝐝 𝐥𝐢𝐤𝐞 𝐚𝐧 𝐢𝐧𝐞𝐯𝐢𝐭𝐚𝐛𝐢𝐥𝐢𝐭𝐲. 𝐈𝐭 𝐢𝐬𝐧’𝐭.

Leaning into the perpetual dilema of Tech Debt

Most tech debt isn’t a technical problem — it’s a decision-making problem.

We chose to optimise for speed. We chose to defer. And we often choose not to address it until it becomes a constraint.


𝐈𝐧 𝐩𝐫𝐚𝐜𝐭𝐢𝐜𝐞, 𝐭𝐡𝐞 𝐭𝐞𝐚𝐦𝐬 𝐭𝐡𝐚𝐭 𝐦𝐚𝐧𝐚𝐠𝐞 𝐢𝐭 𝐰𝐞𝐥𝐥 𝐝𝐨 𝐭𝐡𝐫𝐞𝐞 𝐭𝐡𝐢𝐧𝐠𝐬 𝐜𝐨𝐧𝐬𝐢𝐬𝐭𝐞𝐧𝐭𝐥𝐲:

• They budget for it deliberately — ~15–20% of sprint capacity isn’t “nice to have”, it’s a guardrail

• They quantify it in business terms — cost of delay, lost optionality, slower delivery

• They address root causes — legacy dependencies, capacity constraints, or weak estimation discipline


𝐈𝐟 𝐭𝐞𝐜𝐡 𝐝𝐞𝐛𝐭 𝐤𝐞𝐞𝐩𝐬 𝐚𝐜𝐜𝐮𝐦𝐮𝐥𝐚𝐭𝐢𝐧𝐠, 𝐢𝐭’𝐬 𝐫𝐚𝐫𝐞𝐥𝐲 𝐛𝐚𝐝 𝐥𝐮𝐜𝐤. 𝐈𝐭’𝐬 𝐚 𝐬𝐢𝐠𝐧𝐚𝐥.

Because eventually, every organisation reaches the same point:

You either invest in paying down tech debt deliberately — or you pay for it later through slower delivery, weaker resilience, and lost opportunities.

At that stage, tech debt is no longer a code problem.

It’s a leadership choice.

And like any unmanaged debt, the interest compounds over time.


𝑊ℎ𝑎𝑡’𝑠 𝑦𝑜𝑢𝑟 𝑒𝑥𝑝𝑒𝑟𝑖𝑒𝑛𝑐𝑒 — ℎ𝑎𝑠 𝑡𝑒𝑐ℎ 𝑑𝑒𝑏𝑡 𝑖𝑛 𝑦𝑜𝑢𝑟 𝑜𝑟𝑔𝑎𝑛𝑖𝑠𝑎𝑡𝑖𝑜𝑛 𝑏𝑒𝑒𝑛 𝑡𝑟𝑒𝑎𝑡𝑒𝑑 𝑎𝑠 𝑎𝑛 𝑒𝑛𝑔𝑖𝑛𝑒𝑒𝑟𝑖𝑛𝑔 𝑖𝑠𝑠𝑢𝑒, 𝑜𝑟 𝑎 𝑏𝑢𝑠𝑖𝑛𝑒𝑠𝑠 𝑜𝑛𝑒?



#ProductAtScale#ProductLeadership#ProductStrategy#TechDebt#DigitalTransformation#B2C#Platform

𝑃ℎ𝑜𝑡𝑜 𝑏𝑦 𝐽𝑢𝑙𝑖𝑒 𝑅𝑖𝑐𝑎𝑟𝑑 on Unsplash