Seek forgiveness, not permission (fake it till you make it?)
Career advice disguised as product management tactics
A common dilemma we face as Product Managers is being asked to focus on outputs, when we know that we should be focusing on the outcome instead.
I’m not a fan of Feature Factories, but I’ve learned to stop taking an absolutist stance against the approach ("they're idiots! have they never read Marty Cagan or Melissa Perri?!")
I’ve accepted two truths on this:
This might be what's best for your business at the moment; and
I won't change the entire company's operating and business model from one day to the next.
But that doesn’t mean we’re doomed! In today’s newsletter, I’ll explain how to get unstuck and start nudging your org to see things your way (hint: the advice is in the title).
Let’s get to it.
It might be for the best
"Sales-driven" and "project-driven" often get used as derogatory terms in the Product world. We have our reasons for it, but let's be clear: We aren't always right. Sometimes, a sales-led model really is what's best. The two main cases I've seen for it are (1) when you need to sell to stay afloat (not everyone has tons of seed/VC cash to burn), and (2) that it's a good way to establish product-market fit.
Let's go over the four main reasons why orgs remain sales-driven.
Reason 1: Cash is king
Businesses need cash to stay afloat. Sometimes, that means having to be short-termist. To quote legendary economist John Maynard Keynes: "In the long run, we're all dead": The long run is nothing but a collection of compounding short term decisions (which is also the argument to not be purely short-termist). It's all well and good to think about your long-term vision, but if the company can't survive the journey to your product utopia, it'll all be just a nice story to reminisce about.
Reason 2: Enterprise products are not $20/user/month SaaS
The need for cash isn't the only reason why a sales-driven model might make sense. If you're working on B2LargeB / B2Enterprise products, you're likely looking at a very slow number of deals that are each worth six, seven, or more figures each, and which will all likely require a good amount of effort from sales, product, and engineering to get over the line.
Reason 3: "Product-Market Fit" isn't an intellectual exercise
It's funny how often companies claim to have reached product-market fit for products that have hardly ever been sold. Just because prospects are receptive to your demos ("that looks great!", "this is really smart", "I can see us using this") doesn't mean
Note to the above: My experience is mostly in 0-1 B2LargeB (or internal) data and AI products. I think the case for being product-led becomes a lot stronger later down the maturity curve, and also for smaller ticket sales.
Reason 4: Okay fine, sometimes companies are just silly
The last reason why sales-led growth is here to stay in your org is the one you were probably thinking of from the start: That this is what the business is used to, and that there isn't necessarily a higher strategy behind it. In that case, change might be what's needed - but it'll take time and effort the right kind of effort
Change takes time convincing
Let's say you think your org is too sales-driven (if you're an internal PM like most Data PMs are, you can replace this with something like "important stakeholder needs this asap"-driven). And let's say it's not for, um, sound strategic reasons - but do remember that you're not the CEO, and that you may not see or understand the full picture. PMs are not 'mini CEOs' and should they live under any such delusions.
You have a vision for how your product and company can succeed, if only it were more product-led! Focus on building a great product that sells itself - though you know that doesn't mean the same thing as "build it and they will come". It's about finding the right problems that need solving, and then solving them in a scalable way. Wasn't that why they needed to hire a Product Manager, anyway?
You've tried to explain this to your manager, whose new job title is Product Director, but they've never actually worked as a PM - and it shows. You grow more and more frustrated as you're asked to build useless feature after useless feature, just because a salesperson promised it or because your CMO thinks it's embarrassing to not be able to show that you have all the same features as our competitors. You despair. Where is the upfront discovery? Where is the retrospective evaluation of what's worked well vs. what hasn't? Will we never sunset features that are just adding clutter? How will we know when to double down on something promising?
Or, as an internal data PM, you're churning out tables, reports, dashboards, and models, just because some other project or director is asking for them. Same as your frustrated external-facing colleague, you don't know which ones are adding value versus which ones are just shipped for the sake of it. You don't even know if any of it is being used, let alone what it's being used for. Questions about how much monetary value each output is adding are in the same plane as Iain M. Banks' utopian science fiction novels: Intellectually very interesting, but bear little impact on your day-to-day reality1.
Both of you, the external and internal PMs, are being asked to focus on outputs, not outcomes. And it's not just about keeping your manager happy in your weekly 1:1s - you know this stuff is going to affect your end-of-year performance rating, your chances of getting promoted, and the things you can brag about on your CV.
So you play the game. You pretend burndown charts are an indicator of performance. You push your team to churn things out faster. You proudly display your team's throughput metrics like you're a literal factory trying to meet quota. Every day that passes, you feel less like a Product Manager, and more like a project delivery person. Oh, what would Marty think?
You've gotta play the game - but the rules are changing
Look, if your performance rating and general keeping of the peace depends on delivering the outputs your org expects you to, I'm not gonna tell you to not do that.
But you can't only do that.
Guess what? If you ship all the features that are required -nay, demanded- and they don't translate into any more sales or genuine cost savings or whatever else actually matters to a business' continued survival, nobody is going to celebrate your hard work. At least nowhere nearly as much as when a big customer finally signs or ARR targets are met.
Meanwhile, some other team (or company) might get lucky. They'll happen to sign a customer not because of the brilliant plan to get them, but just because the customer was ready to sign. Or because they were in a rush to spend their annual budget before losing it next year. Or because one of their VPs went to school with one of your VPs. Whatever. And that team may well be hailed as geniuses. Their PM gets fast-tracked for promotion, their performance bonuses are 2x that of everyone else, and their CVs tell a pretty damn compelling story.
That's the trouble with aiming for outcomes, by the way. You won't be able to control them nearly as well as outputs. A macroeconomic shift might make everything 10x harder, or 10x easier. A competitor pivoting to something stupid might open up opportunities for growth. Another's raise might raise your cost of acquisition significantly. But that's business - it's not fair. And at the end of the day, outcomes are what we're after. It's just that so many of us work for sufficiently large and complicated orgs that we can hide away behind excuses and convoluted performance management systems that we can spend our entire career destroying more value than we create.
Okay, that was a bit grim. Sorry. But you know it's true. You see those people all the time. All they seem to do is fail upwards. And a lot of corporate cultures will continue to reward them. Maybe they've just been better at playing the game than you.
But things are changing. Much like the rest of the tech sector, data teams have benefited from over a decade of cheap money, high FOMO, and the benefit of the doubt about when companies can expect to see a positive ROI.
Here's a couple slides I shared at my talk at the Athens Analytics & BI meetup a few months ago:
My argument was twofold:
These are things more companies will increasingly demand, if they aren't already
Data teams should look to provide and demonstrate their value contribution before they are asked - because it might be too late by the time that happens
Try, as much as you can get away with, to do what's most likely to trigger the desired outcome. Even if it's not your job. Even if nobody is asking for it.
Remember: Show, don’t tell!
Play the game, but cheat too
“A rising tide lifts all boats.”
That's what my example about the team stumbling onto success earlier was about: If your product is doing well, if it's growing, if it's returning a healthy profit - that's the rising tide. Same for your overall company performance. Otherwise you get fun situations like layoffs, hiring freezes, micromanaging leadership, and all those other things that often turn into self-fulfilling prophecies.
So how do we raise the tide when that's not our job?
Here's the advice: Try, as much as you can get away with, to do what's most likely to trigger the desired outcome. Even if it's not your job. Even if nobody is asking for it.
Show, don't tell. And do that while seeking forgiveness, not permission.
If you go to your manager saying "I think I should spend 2 weeks interviewing users and doing prototype testing before we start building this next feature", there's a good chance you'll be told no. If your leadership isn't used to working that way and doesn't see the value of that work, then mentioning some books or courses you took won't do much.
Contrast that with showing up saying "Hey, I've been showing some of our friendly customers mockups of the dashboard, and everyone has been positive about X, but also negative about Y. I took the initiative to mock up an alternative to Y and that seems to be more popular. Should we go ahead with Y(a), or would you like us to go ahead and develop Y(b) instead? I can send you the interview recordings and summaries if you want to dive deeper"
Over time, people will see the value of this work, and expect it. But not until they see the results.
That's what I've done for the bulk of my career. To some extent, it's about being proactive and not expecting to be told what to do every step of the way - problem solving! But other times, I was very much doing what I thought needed to be done, even when I was sort-of-and-sometimes-literally told to not waste time doing those things.
Epilogue
One line that never really comes up in the job descriptions of jobs I've applied for is that a PM needs to educate their teams and colleagues. Sure, sometimes there's stuff about evangelising their product, or helping develop data literacy, but it's never about "educate your team on what the hell a product manager does all day".
And yet that's a line I've consistently had to add to my own JD.
I'm sure data scientists 10 or 15 years ago were having to do the same. If you've been hired by people who don't know what you know, and have never done what you're doing, of course you can't expect them to have the playbook laid out for you from the start. And they aren't always aware of this, or they are, in theory, but when push comes to shove, their own instincts kick in about what's important, relevant, or required.
I've seen folks who have been hired into these kinds of complex, high-ambiguity, high-agency-requiring roles and just followed orders. It doesn't go very well. The reaction from their team or their stakeholders or their manager goes along the lines of "yeah, they're a bit useless aren't they?" behind their back, because they don't really understand how that person is meant to be useful. It just feels like they're not doing things right.
A PM needs to have high agency in order to succeed. You can't just do as you're told. I mean, you can, but then you're probably fooling yourself a little bit about the exact line of work you're in 😅
Epilogue after the epilogue
An offer to help out, bundled together with me asking for your help.
I’m working on a course for Data PMs, and I’d love to hear from folks interested in it. If you’d like to share your thoughts book a free coaching call here. Or maybe you’re not interested in the course, but want the coaching anyway - that’s a totally valid reason to book a call too 😊
Actually, even the most utopian sci-fi is applicable to the real world usually, but you get my point.