Minute Monday 17: The broad brush strokes trap
Discover more from The Product-Led Geek
Minute Monday 17: The broad brush strokes trap
Stop making this mistake
On the whole, I believe that developers are a perfect fit for a product-led go-to-market motion, and I think this reflects some preferences that are typical amongst developer communities.
But here’s the thing.
The statement above might be true.
But any time you make a statement like that, think about whether you really know enough to have confidence in it and whether a more nuanced perspective would be advantageous.
If you don’t, you fall into the broad brush strokes trap.
When you fall into this trap, you make generalisations.
Generalisations damage your ability to understand and serve your audience well.
Continuing to use developers as an example, you start to say things like
Developers don’t want to talk with you.
Developers hate salespeople.
Developers this.
Developers that.
All of the above is true about some developers.
But developers are about as varied a bunch of people as you’re likely to encounter.
Treating your users with broad brush strokes is a mistake that will hurt your business deeply.
Think about the role nuance that you’ll find under the umbrella of ‘developer’
Application Developer vs Platform Developer
Growth Engineer vs Distributed Systems Engineer
Front-end Developer vs Full-stack Developer
Web3 Developer vs Mobile Game Developer
When you fall into the broad brush strokes trap, you start getting lazy.
You lose curiosity.
You lull yourself into a false sense of knowledge that leads to creating suboptimal solutions.
Are there some common traits that you might commonly see across a significant sample size of different types of developers?
Sure.
There’s usually some lowest common denominator stuff that can be useful as you build your go-to-market motion.
But start prefixing your statements with ‘Most’ or ‘Some’ to get you and your team out of this trap.
Most developers want to create and build.
Most developers enjoy learning new skills.
Some developers want to craft highly robust and well-documented code.
Some developers thrive on fast iterations, feedback loops and user impact.
Most developers have a low tolerance for BS.
Most developers bias toward the ‘Feel’ end of the Feel > See > Hear spectrum.
Some developers genuinely care about security.
Even better, get specific.
Who are the different sub-types of persona that you’re trying to serve?
Who are you not serving?
For those that you’re serving, what do they care about?
What problems do they have?
How do those problems differ from other sub-types?
Where is there overlap?
What are their values?
And then start to think about the context these users exist in.
If you’re in B2B, that context will inevitably be a team.
Ask those same questions about the team.
All of this should be ongoing and continuous.
Having a higher fidelity representation of your users is never a bad thing.
You can always zoom out and spot the patterns where a broad brush is OK.
It’s the lazy broad brush strokes that are the problem.
Where a fine brush would capture important detail and nuance that lets you serve and engage with users more effectively, using a broad brush stroke masks opportunity.
Minute Monday 17: The broad brush strokes trap
One interesting dichotomy is engineers who like to be told what to build vs. those who like to collaborate as part of the Product Trio throughout the Strategy, Goal-Setting, Discovery, and Delivery processes.
Essentially looking for engineers to take on more of a Product mindset invested in driving Outcomes vs. a Project mindset focused on delivering Outputs.
You might find this interesting, Ben -
I had a lively exchange with Hiten Shah on Twitter / X about his perspective on Engineering-Driven Development, basically the trend to have engineers be their own Product Manager.
Here's the original piece: https://www.june.so/blog/the-rise-of-engineering-driven-development-edd
And here's the thread with Hiten's comments: https://twitter.com/michaelgoitein/status/1690155222948036608?s=20