Solving for them vs Solving for us

Yesterday I had a chat with my great friend @jularase yesterday about building, and what to build, and how we build.

She said that she's got no interest in solving her own problems, which I found fascinating. It immediately contrasted in me that most of the stuff I choose to build fixes my own problems. I "choose" in the context of me starting a new company, or starting a new open source project, or even a tiny SaaS.

It contrasted because I love validating that it can have a larger impact on something. A larger impact on an organization or an industry for example. I love validating that there are good dynamics in the market and we are not just building into a dead end where –i don't know– regulations will eat our profits in the years to come.

I love validating that we are actually building the right thing.

But ultimately for me this tends to starts with "i don't like this. let me fix it", and goes from there to "oh, a variation of this can be good for a larger audience/market/industry/whatever".

It doesn't really start with "lets see what's the most impactful thing i can do".

For example, I do this all the time when building:

• I ask myself what's the biggest bang for buck i can get to solve X?
• Or when making leadership decisions about structuring and organization, what's the incentive structure?
• Or when dealing with unforeseen circumstances, I ask myself what's the playing field look like? What do we do now that puts us in a better position than a moment ago? What about this situation/architecture/conflict can we use in our advantage, right?

How can we have more "impact" through less work. Maximize the outcome, minimize the inputs.

But this kind of talk is super fluffy and I don't like engaging in it. I like the doing of strategy, I like the understanding of strategy, I don't like the "strategy talk".

One example from a recent product I'm building: we need to make sure people's data is kept safe and isolated. So we decide that namespaced resources are the way to go. But we don't build the automatic namespaced resource creation, we just decide on what the namespacing should be, then create what you need right now manually, and move on. You get the benefit at a fraction of the cost of automation. Then later when you have an established pattern to automate, you can do it. Bang for buck.

Another example from a fast-scaling startup I consulted for: we needed better ways to standardize how people built across the organization. Design patterns if you will. But we didn't go about establishing what patterns people could choose from. Instead we introduced a meta-pattern that would build the pattern over time. And this was a communication pattern: RFCs. So by introducing RFCs, also not as a big pattern but rather just start pumping 'em out, you slowly introduce a few ideas into your dev culture:

• it's desirable to get feedback early
• it's acceptable to make mistakes,
• it's important to understand the problems,
• and ultimately that collaboratively we can achieve excellence.

This is also a little fluffy, but over time means that people notice and evolve patterns on their own. Those patterns stick a lot longer and run a lot deeper than the ones you had people down in an Engineering Handbook or whatever. And it took us just a few RFCs before RFCs were a thing, and the meta-pattern lead to the development patterns we wanted.

Plant a seed vs. implant a tree sort of thing. I love that.

At the outset, when looking at what to build, I think for me its usually an intrinsic driver rather than an extrinsic one. It's not "Oh look at these people they have a problem I can fix for them" but rather "Who else out there has the same problem I have/had".

I'm tempted to argue that building for yourself has a lower-bound of 1 person impacted by what you're building, vs building for others which has a chance no one out there will use it.

Intrinsic vs extrinsic drive.

When you look at it like this, it makes sense for anyone in a product role to be obsessed with the problems rather than the solution. But it also is a self-asserting prophecy: most people in product roles out what to build for others, not for themselves, so they end up caring more about others' problems rather than their own.

The same happens for builders, and I think its a reason we have a universe of developer tools that solve our own problems. We are so close to solving that when we find a problem, we just find how to fix it and need to make a conscious effort to step back and ask where we should.

Anyway, I'm reminded that the needs of the many outweigh the needs of the few, or the one, and it makes me feel a little guilty that I may not be as Starfleet as I think I am when it comes to fixing things.

Sorry, chief O'brien, I'll try to do better.