- Lessons Learned the Hard Way
- Posts
- Job description red flags
Job description red flags
Also: GenAI and platforms vs aggregators
Job descriptions often have red flags if you know what to look for.
Red flag #1: The company treats Product like a delivery engine, not a strategic partner
Say no to: SAFe, Product Owners, reporting into Marketing / Ops1 / Engineering2 , “heavy” collaboration with the founder / CEO, owning the roadmap and execution but not strategy.
Red flag #2: Combining two roles into one
Say no to: Player / coach roles (these have become more popular lately but that doesn’t make them a good idea), combining PMM or Marketing with PM, doing wireframes or SQL (unless it’s really early stage3 ).
Red flag #3: The job has been on the market a really long time and/or gets frequently reposted
Probably a sign they want a unicorn or have scared off a lot of good candidates. Or it’s a scam and not a real job.
Red flag #4: Over the top language (ninja! guru! rockstar!) and excessive use of emojis
Is this a serious organization? Why are we trying to attract 5 year olds?
Red flag #5: Reinventing the wheel
Some founders have this urge to prove (or believe that) they’ve invented something better than the industry standard. So they’ll come up with “innovative” interview processes, company values statements, ways of doing job titles and levels, compensation, etc. It’s almost always worse and usually a sign of how chaotic actually working there will be.
Someone should create a wall of shame for job descriptions. I’d love to contribute.
(Thank you to Cassidy and Greg for your help with this post!)
The Workshop
This is a newsletter-only section where I share a half-baked idea in hopes that y’all who are smarter than me can work it out with me.
This is really, really early thoughts so I’d love your input.
This week’s launch of Microsoft Copilot+ computers and the launch, several months ago, of OpenAI’s GPT marketplace made me realize we’re seeing a classic platform vs marketplace competition play out in front of us. I’m really interested to see which model wins.
Platforms create environments where the platform developer owns the relationship with the end user and value created by developers exceeds the value of the platform itself. Typically, the platform charges a subscription fee to the developer. Microsoft has this in their DNA thanks to Windows. Shopify, Amazon Web Services are other examples.
Marketplaces aggregate demand, which forces suppliers to do things they don’t want to do — share a % of the profits, spend time and money integrating with the marketplace in modular ways that commodify them — in order to get access to that demand.
Both are great models. And there’s a whole other post I plan to write about how risky it is for companies who are one model to try and also be the other (imagine if Squarespace also launched a direct-to-consumer marketplace, and started competing with their own clients for transactions, and charged a % marketplace transaction fee on top of the monthly platform subscription fee).
My money is on platform. Yes, I’m a marketplace guy. But I think it’s much more likely the big GenAI companies become the next AWS than become the next Google.
1 Reporting into a GM can be OK as long as the GM is a product-minded one. What you want to avoid at GMs who think their job is to tell product what to do. But if they think in terms of hypotheses, and see Product as part of the toolkit for proving out hypotheses (“how might we…”), then that can be a great relationship.
2 I’m not completely against reporting into a CTO but I’m very skeptical. I’ve typically found CTOs to be light on strategy and heavy on either 1) building whatever stakeholders want, 2) building whatever would make engineering’s lives easier, 3) building an excessive amount of tools and measures.
3 And even then, what are we doing? Why don’t we have a designer? Is standing up something free like Metabase so hard that we’re forcing SQL on PMs? In what world is instrumenting our code so that we can use BI tools so expensive that we would instead have our PMs learn data architecture and querying (god help us) production DBs?
Reply