I really like Richard Feynman’s idea of having a dozen problems that you actively search for answers to. Then whenever you learn something new, you can test it against these problems.
One of my problems is “What can you focus on as engineering manager if you can no longer scale? Is it only faster, cheaper, reduction of complexity? Or perhaps quality improvements, developer experience, system reliability, or team capabilities?”
Do you recall the last time you took a picture of a sunset? Unless you are a professional photographer it probably looked terrible on your phone.
Building your own products can feel the same way. We judge their external polished front with how our messy process, discussions or iterations feel.
It’s for all those people that have nowhere or no one to talk to about their deep thinking. To test their ideas. While it can’t replace human creativity, it stands ready as a patient analytical partner whenever inspiration strikes.
Good decisions come from understanding the whole business. Learn your operations. Study your finances. Know your culture. This knowledge shapes better choices.
The first idea is just a spark.
Through iteration. Through persistence. Through pure stubbornness.
That’s how you turn a tiny spark into a fire.
We need to master languages for the future. Not just any language. The language to be clear with machines and humans.
Think about making an app. You need words to explain views. Canvas. Navigation. When you talk to AI you can’t just say “make me a game”. You need to say “I want a browser game for phones. With a high score list that works like this”.
That is vocabulary. But soon everyone will know these words. Everyone will generate apps and games. That is when taste becomes important.
Anyone can make a game today. But making something that feels good. That is different. That takes taste.
Vocabulary lets you tell the machine what to build. Taste lets you make it worth building.
Less is more means doing more with less.
Focus on a few things and master them completely.
I’ve struggled with estimates for years.
We’re asked “how long will this take?” as if we’re building something we’ve built before. But in product development we’re creating something new every time, within the constraints of our tech stack, frameworks, and past decisions.
Many teams are starting to talk about appetite instead of estimates. It changes everything about how we approach the work. Instead of “can we build exactly this?” we ask “what’s the best we can build in the time this is worth?”
To get to a meaningful appetite:
Then bring all of this context to your team. Let them understand not just the time box. But the why. Because an appetite isn’t a time constraint. It’s a value decision about how much of your company’s resources should focus on this solution.
Problems start when what you expect doesn’t match what actually happens.
Be explicit of what you expect and make sure you understand what is expected.
When conflict arise, take a step back and check if it is simply a case of different expectations. I’ve often seen disagreements that are just people working from different assumptions.
People are more likely to reject a polished final product than suggest changes to it.
But they’re far more comfortable giving feedback on a rough draft or prototype.