I read Gene Kim Sensei’s first book, The Phoenix Project, a while back. That book talks about DevOps challenges. I could follow the story even though many of the terms were unfamiliar to me at the time, so I had to stop and search for their meanings on Google along the way.
Lately, I have been interested in learning about product engineering. I asked AI for book recommendations on product, and one of the books it suggested was The Unicorn Project. When I saw the cover, it looked familiar, and indeed it was also authored by Gene Kim Sensei. So, I grabbed it right away and started reading.
I finished the book in a week as part of my campaign on X to read one book a week. I learned a lot from this novel, and I want to group those lessons into categories: good engineer habits, engineering culture, product and business, and organization and leadership. Below are the ideas I captured from reading the book. I might have missed some, so tell me on X what I missed.
Good engineer habits
Keep a working diary
Taking notes is an underrated habit for an engineer. In the book, Maxine keeps a working diary where she writes down what she is working on, how much time she spends on each task, and the lessons she learns along the way.
Writing down common problems and how you solved them keeps you from hitting the same wall twice. Memory fades fast when you are debugging complex issues. A simple log of errors, commands, and root causes saves hours the next time a similar bug shows up.
Document the system and map the features
Documentation is always important, especially when a system grows across many teams. In The Unicorn Project, Maxine spends days trying to run a build because the knowledge lives only inside people’s heads and outdated wiki pages.
A team should maintain a clear feature map and document how to access and run each part of the system. When any engineer on the team can read the docs, trace how a feature works, and spin up the service locally, the whole team moves faster.
Write code that is easy to change
We should always aim for programs that are easy to change. Working code is the baseline, yet code that resists change slows down every future feature.
The book references Rich Hickey’s idea of avoiding complected systems. To complect means to braid or tangle separate concerns together until you cannot touch one part without breaking three others. Keeping modules separate and decoupled makes future changes safe and predictable.
When a codebase suffers from unexpected bugs caused by mutating global state, functional programming principles can help. Passing immutable data through pure functions removes hidden side effects. You do not need to switch languages to apply this. You can start by isolating state mutations and keeping your core logic pure.
Care about data, even if you are not a backend engineer
Every engineer should act as a custodian of the database, regardless of their role. Frontend, mobile, and product engineers all consume and shape data.
If data definitions are messy or inconsistent at the source, every downstream feature suffers. Understanding how data is stored, queried, and migrated helps you build better features and prevents corrupt state from creeping into production.
Engineering culture
The Five Ideals
Gene Kim frames the technical and cultural lessons of the book around the Five Ideals:
- Locality and simplicity. Build modular systems so an engineer can make a change in one place without coordinating across ten teams or breaking unrelated components. In the story, a simple change takes weeks of approvals because everything is tangled together.
- Focus, flow, and joy. Create an environment where engineers can concentrate without constant interruptions, ticket bureaucracy, or broken build tools. When feedback loops are fast and tools work, solving problems brings genuine joy.
- Improvement of daily work. Pay down technical debt and fix broken workflows every day. Prioritizing daily improvements over shipping feature after feature keeps the system healthy.
- Psychological safety. Build a culture where people feel safe asking questions, admitting mistakes, challenging bad ideas, and running experiments without fear of punishment.
- Customer focus. Measure work by the real value it delivers to customers, rather than by internal vanity metrics or how many tickets the team closes.
Technical debt and compounding complexity
One quote from the book that I remember:
Technical debt is what you feel the next time you make a change.
When a team works only on new features and ignores the health of the codebase, complexity debt compounds. Every shortcut adds friction to the next deploy. Eventually, the team spends all its energy fighting the system just to ship a tiny update.
Part of our job is helping other engineers do their work with less friction. Whether that means automating a manual setup step, fixing a flaky test, or cleaning up a confusing module, making daily work easier for your teammates multiplies the output of the whole organization.
Blameless postmortems
To build a blameless culture, start by assuming that everyone on the team is doing their best with the information and tools they had at the time. When an outage happens, firing or shaming the person who pushed the commit only teaches the rest of the team to hide their mistakes.
This also reminds me of my previous review of Thinking in Bets and the bad habit of resulting. Resulting is when we judge the quality of a decision purely by its outcome. An engineer can make a reasonable decision with the information available, and the deploy can still fail because of hidden system traps. Blaming the engineer for a bad outcome confuses the result with the effort.
During a postmortem, focus on building an accurate timeline of what happened, which events occurred, and how the team detected the issue. Look at the system that allowed the error to reach production, and add safeguards so the next engineer cannot fall into the same trap.
Product and business
Know your users and build real value
The goal of software development is to create value for the customer. To do that well, you need to know who your users are and what problems they face in their daily work. Seeing real users struggle with your product builds empathy and motivates you to work with care.
There is a big difference between people who create value and people who just do their jobs. Closing tickets and writing code all day means very little if the output does not solve a real problem for the user or move the business forward. Good product engineers optimize for time, cost, performance, revenue, and user satisfaction together.
Choose technology for the long term
Picking a technology stack is a long-term commitment that should help the product last. Chasing a shiny tool for a short-term win often leaves the company with an unmaintainable system a year later.
When you choose a tool or architecture, think about the people who will maintain it in the future. Choose technologies that your team can understand, debug, and operate years from now.
Core versus context
What is core to your business today may become context tomorrow. Core work is what differentiates your product and wins customers. Context work consists of the supporting systems, such as payroll or standard infrastructure, that must work reliably but do not set you apart from competitors.
The book illustrates this with the story of the Chief Power Officer. Back when factories first adopted electricity, companies had to build and run their own power plants just to keep the machines running. Generating power was a core capability, so companies needed a Chief Power Officer to manage it. Once public power grids became reliable, factories outsourced electricity to utility companies. Running a power plant was no longer core. It became context, and the Chief Power Officer role disappeared. Over time, yesterday’s custom innovation turns into a standard commodity, and you have to keep shifting your energy toward new customer value.
The Three Horizons
To survive long term, a company has to balance today’s revenue with tomorrow’s bets. The book introduces Geoffrey Moore’s Three Horizons model to explain how businesses allocate their attention:
- Horizon 1: Core business. Maintain and improve the existing products that generate revenue and keep the lights on today.
- Horizon 2: Emerging business. Build and scale new product lines that are starting to grow and can become the next core business.
- Horizon 3: Future innovation. Run small experiments and explore new ideas that could transform the business in the future.
Large companies often fail at Horizon 2 and Horizon 3 because they judge new experiments by Horizon 1 rules. A tiny prototype cannot survive if it has to pass the same heavy approval processes and revenue targets as the main product. Teams working on future horizons need room to experiment, fail fast, and learn what customers want before scaling up.
Organization and leadership
Shared goals and ownership
A team works best when everyone shares a common goal for what success looks like. Cultivating a sense of ownership across the team aligns engineers with that goal.
When leadership sets clear goals and gives engineers real ownership, the team can self-organize to reach the target. Leaders do not need to micromanage every task when the people closest to the code understand the mission and have the authority to act.
Self-organizing autonomy and finding your tribe
In The Unicorn Project, a group of engineers forms “The Rebellion” to cut through bureaucracy and fix the company’s biggest bottlenecks. They operate with self-organizing autonomy, solving real problems together instead of waiting around for management to hand down permission.
Find your tribe at work. Surround yourself with people who care about bringing excellence to the project and who want to make things better.
Be proactive for the good of the product
If you see something that will help the organization reach its goals and make the product succeed, be proactive and go after it shamelessly. Speak up, propose the change, or build the prototype. Waiting for someone else to fix a broken process keeps everyone stuck, while taking initiative can spark the momentum the whole team needs.
My biggest takeaway from this book is what real ownership looks like in practice. I am amazed by how proactive and adaptable Maxine is when she pushes for a better engineering environment and innovates on the product. She refuses to stay inside her code editor and wait for requirements to land on her desk. At one point, she even works as a retail store trainee at Parts Unlimited so she can experience how store staff interact with customers and feel the pain points they deal with every day. That kind of curiosity and care for the people using our software is what turns a good coder into a great product engineer.