Here's the book to read if you want to better understand what product managers/owners do. I enjoyed it.
This book pairs well with the empowered teams model.
Products, not projects
Marty Cagan, the author, argues that the winning feature of modern software teams is a focus on products over projects.
A product is something you own long-term and iterate. You're looking to achieve a business goal and you don't stop until the goal is achieved.
A project is something you do. You're pursuing a deliverable and whether it works or not is not your problem.
Projects can be a tool in product development (like building the next iteration of your product), but they're not the path to tech products customers love.
Continuous product development
The main difference between building a product and building a project is that product work never ends. You continuously iterate and make improvements.
Like kicking a can – every iteration unlocks new possibilities and improvements. Users see the new thing and think "Wow amazing, what if it could also ...".
Neither you nor the users could think of that improvement before seeing the improved new version. It wouldn't cross your mind. Too far into the unknown. The adjacent possible is everything.
Innovative products come from thinking "What has technology just now made possible that was too difficult to do before?".
No roadmaps
You need to know where you're going, of course. At least for the near future.
But stiff roadmaps are an organizational yellow flag. Roadmaps like to devolve into laundry lists of features and ideas to build.
Someone thought of a solution to their problem 6 months ago, put it at the end of the roadmap, and by the time you build that feature they no longer care. Or the problem has changed. Or the system has changed. Or ... point is: feature roadmaps bad.
Instead you want a roadmap of problems to solve. Objectives to achieve. What are the business metrics you want to move? What are your best guesses on how to do that?
Focus on the business outcome, not the feature.
Minimum viable product
Everyone knows about MVP these days – minimum viable product.
But as an industry we focus too much on the minimum part and not enough on the viable part. Shipping broken software that's cumbersome to use is not MVP. That's just broken software.
Instead you should focus on solving the problem with the minimum number of features for a specific segment of customers. It's okay if your new idea doesn't work for everyone in its first iteration. Pick a segment. Solve the problem. Iterate until they love it. Expand.
Solving it is key. Nobody's gonna use your broken feature.
Durable teams
You can't do this with a feature or internal agency team model. Or, worse, external agencies and contractors.
You need people who work together on a product long-term. This need not match reporting structures. It's fine to grab people from different teams to create a squad or whatever.
Focus on a single product that you own builds depth, evolves understanding, and helps you get it right.
Involve technicians earlier
Engineers and designers should be involved as early as possible. While talking to customers is best.
Cagan argues that some of the best ideas come from engineers and product designers who deeply understand both the problem domain and the technological adjacent possible. They see solutions others miss.
You want to include them early in the process because as the people building your ideas (Cagan writes to product owners), they'll tell you what's possible, when you're dreaming, and even when you're not thinking big enough.
In my experience product owners often fear something is super hard when it's actually easy. Likewise they think super difficult things are trivial. That's our fault as engineers. It's the balls of mud that make this hard to predict :)
Talk to more customers sooner
This is the big one – get out of the building and talk to people.
Make a prototype. Shop it around. See what people say. The earlier you can iterate with user/customer feedback, the faster you can move.
Don't wait until you spend 6 months building a thing. Take that rough mockup and talk to users. Paint a picture with words and handwaving if you have to. Kick the can.
Cheers,
~Swizec
Continue reading about What I learned from Inspired
Semantically similar articles hand-picked by GPT-4
- Get us over the water, not build us a bridge
- A better roadmap solves many issues
- "Yes caviar is great, here's a ham sandwich"
- Working with product
- Can I get your opinion
Become a *true* Senior Engineer
Get promoted, earn a bigger salary, work for top companies
Getting that senior title is easy. Just stick around. Being a true senior takes a new way of thinking. Do you have it?
The Senior Minset email crash course
Get a free chapter from the Senior Engineer Mindset book and a sample audiobook chapter, followed by a Senior Mindset 101 email course.
You'll get insights to apply at your work right away.
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️