The Product Culture Shift(elidedbranches.com)
elidedbranches.com
The Product Culture Shift
https://www.elidedbranches.com/2022/08/the-product-culture-shift.html
7 comments
I couldn't disagree with your points more, so I'll address them in detail. Thinking of in-house software as a product is useful at modern, flexible companies; and here's why:
> It does not have real pricing.
It absolutely does have real cost pricing, in terms of the number of engineers working on it! This is why internal tools or developer productivity teams at the typical Dunder Mifflin Paper Company style orgs are chronically underfunded, and generally seens as a joke by the business people — which naturally leads to bad hires and a generally weak effort in that direction. It's self-fulfilling downward spiral.
A bunch of modern companies counteract that by treating internal tools and developer productivity as a product, which communicates not just the cost, but also the effective advantage that the company gains, and improves it over time just like the company's external-facing products would.
> You can't sell more of it and increase the customer base.
There are innumerable exceptions, but a single 27 billion dollar one is Slack, which started off as an internal tool [1] for Stewart Butterfield's company Tiny Speck.
> You can't drop money-losing products.
Wrong! In fact, you can absolutely drop "money-losing" products that don't have enough internal customers, and do a much better job than a tired team without a product mindset complaining that "no one uses this tool anyway" as they try to fix a ticket that was filed 7 years ago.
> Here's a classic memo on that subject
I don't know about "classic", it seems to be the experience of one company selling proprietary software that was founded 40 years ago, and very likely has a captive market due to a first mover advantage. I strongly counsel anyone starting out today against having over-applying this narrow "What business is the company in" mindset. In my experience, it encourages frat-house "I am working on the real product" attitudes, and destroys internal productivity, because zero people are incentivized to think positively about that.
----------------------------------------
[1] https://en.wikipedia.org/wiki/Slack_(software)#History
> It does not have real pricing.
It absolutely does have real cost pricing, in terms of the number of engineers working on it! This is why internal tools or developer productivity teams at the typical Dunder Mifflin Paper Company style orgs are chronically underfunded, and generally seens as a joke by the business people — which naturally leads to bad hires and a generally weak effort in that direction. It's self-fulfilling downward spiral.
A bunch of modern companies counteract that by treating internal tools and developer productivity as a product, which communicates not just the cost, but also the effective advantage that the company gains, and improves it over time just like the company's external-facing products would.
> You can't sell more of it and increase the customer base.
There are innumerable exceptions, but a single 27 billion dollar one is Slack, which started off as an internal tool [1] for Stewart Butterfield's company Tiny Speck.
> You can't drop money-losing products.
Wrong! In fact, you can absolutely drop "money-losing" products that don't have enough internal customers, and do a much better job than a tired team without a product mindset complaining that "no one uses this tool anyway" as they try to fix a ticket that was filed 7 years ago.
> Here's a classic memo on that subject
I don't know about "classic", it seems to be the experience of one company selling proprietary software that was founded 40 years ago, and very likely has a captive market due to a first mover advantage. I strongly counsel anyone starting out today against having over-applying this narrow "What business is the company in" mindset. In my experience, it encourages frat-house "I am working on the real product" attitudes, and destroys internal productivity, because zero people are incentivized to think positively about that.
----------------------------------------
[1] https://en.wikipedia.org/wiki/Slack_(software)#History
As an aside, that document is fantastic, I'd never seen it before, went to the start, and now I'm finding it very difficult to stop reading.
The Autodesk File is fabulous. Timeless advice in many places, alternating with interesting glimpses of the early software industry.
For that matter there is a bunch of interesting stuff at the fourmilab site.
For that matter there is a bunch of interesting stuff at the fourmilab site.
So this is like the opposite of Amazon, who rents out their previously internal only systems?
Be careful about hiring product managers. TFA warns that they can become a glorified backlog groomer and black hole for tickets. They can also become another point in a game of broken telephone between your users and your engineers. If this starts to happen in your organization it can cause a lot of dysfunction.
The key for me has always been: talk to your users. If your software engineers don’t know at least some of the users on a first name basis they need to step it up. Software engineers are generally a well educated bunch who are capable of listening to users and prioritizing work when given the chance.
A good product manager is going to know that and work with the team to provide extra support above and beyond those capabilities. They should enable teams to scale with the number of customers but not be the single point of contact with them.
It’s all about communication and playing broken telephone with error reports, requirements gathering, etc is a quick way to lose team effectiveness over time.
The key for me has always been: talk to your users. If your software engineers don’t know at least some of the users on a first name basis they need to step it up. Software engineers are generally a well educated bunch who are capable of listening to users and prioritizing work when given the chance.
A good product manager is going to know that and work with the team to provide extra support above and beyond those capabilities. They should enable teams to scale with the number of customers but not be the single point of contact with them.
It’s all about communication and playing broken telephone with error reports, requirements gathering, etc is a quick way to lose team effectiveness over time.
Software engineers need to step it up ? Many times organizations purposefully put distance between customers and engineers. I like working with the customer directly , but it can be easy to put your foot in your mouth when you are so far away from the contract. Bad customers may also try to exploit this lack of knowledge and ask for extra work outside the contract scope.
I agree, but I am a little biased here as a product owner. Developers like to code. It's what they were hired to do, and it's what generates the most value the fastest. Anything which pulls a developer into meetings is lost productivity. There are occasions for devs to speak with end users; during, for example, refinement and demos. However unless I am vigilant, the developers quickly end up spending most of their time wasted in meetings with four other managers.
You hit the nail on the head: developers aren't well versed in customer and office politics, and most of them don't want to be. I am, as part of my job, and I know who is trying to muscle their pet project into the next sprint. I am the buffer; the diplomat and negotiator; and my team seems very happy with this arrangement.
You hit the nail on the head: developers aren't well versed in customer and office politics, and most of them don't want to be. I am, as part of my job, and I know who is trying to muscle their pet project into the next sprint. I am the buffer; the diplomat and negotiator; and my team seems very happy with this arrangement.
I’m not talking about sales here.
I’m suggesting that developers should know some of their users as people who use their software and talk to them semi-regularly. Especially when your company is small and still trying to find a market fit.
I’m suggesting that developers should know some of their users as people who use their software and talk to them semi-regularly. Especially when your company is small and still trying to find a market fit.
Beeing a Product Manager myself I agree there can be a risk. But there are other situations that demand alot of work like I am now doing: The product is customer facing and has been developed for years with marginal success. Management expects now a new direction backed by insighths and data.
Drawing multiple scenarios of new strategies, talking to customers, setting up market research and getting sometimes pushed back hard is a fulltime job. And I didn’t even get started about traveling globally to meet customers and go to conferences. I just barely can keep up on the side with new technology and trends.
A good PM should be able to do this grindwork and get as much as possible insights to bring it to engineers and bring engineers closer to customers.
I think one doesn’t need multiple PMs and especially not PO to only groom backlogs, here I agree with you. But there is alot of work in dealing with uncertainty, ideas, strategies and put onto paper to have good discussions/discovery.
Drawing multiple scenarios of new strategies, talking to customers, setting up market research and getting sometimes pushed back hard is a fulltime job. And I didn’t even get started about traveling globally to meet customers and go to conferences. I just barely can keep up on the side with new technology and trends.
A good PM should be able to do this grindwork and get as much as possible insights to bring it to engineers and bring engineers closer to customers.
I think one doesn’t need multiple PMs and especially not PO to only groom backlogs, here I agree with you. But there is alot of work in dealing with uncertainty, ideas, strategies and put onto paper to have good discussions/discovery.
> If your software engineers don’t know at least some of the users on a first name basis they need to step it up.
I have both customer support and developer experience. The customers your engineers will know on a first-name basis are probably the troublemakers: the ones who consume $100,000 in support costs for a $20,000 contract; the ones who always have another "helpful" suggestion for irrelevant new features; the ones who have psychological issues and form parasocial relationships with your team because even their own coworkers can't handle them. I have personally seen all these things several times over.
Not to say that dev staff talking to customers is bad, just that it's very human and you have to watch out for all manner of things you wouldn't expect from reading some abstract blog post.
I have both customer support and developer experience. The customers your engineers will know on a first-name basis are probably the troublemakers: the ones who consume $100,000 in support costs for a $20,000 contract; the ones who always have another "helpful" suggestion for irrelevant new features; the ones who have psychological issues and form parasocial relationships with your team because even their own coworkers can't handle them. I have personally seen all these things several times over.
Not to say that dev staff talking to customers is bad, just that it's very human and you have to watch out for all manner of things you wouldn't expect from reading some abstract blog post.
Product should be the glue between teams and create efficient flow of data between stakeholders.
Imo the problem with Product Manager is it's a catchall term when there are 4 types.
Research, OPS, UX/UI and technical. They are all very different in their execution and value but they are seen by some as 'you manage the backlog but with data to prove my ideas aren't wrong'
Zero point of having a PM if this is how they get deployed.
It's too bad as the role, when assigned and matched well, can cut through to the core pain points.
Also 100% agree, you want to talk to high, medium and low supporters to get a good map.
For one I worked at, I deployed receptive.io (now part of Pendo) and it showed every customer demographic wanted a specific feature and ALL their great ideas where shit on by the users.
The echo chamber at C level is, imo, the reason PMs get sidelined.
Imo the problem with Product Manager is it's a catchall term when there are 4 types.
Research, OPS, UX/UI and technical. They are all very different in their execution and value but they are seen by some as 'you manage the backlog but with data to prove my ideas aren't wrong'
Zero point of having a PM if this is how they get deployed.
It's too bad as the role, when assigned and matched well, can cut through to the core pain points.
Also 100% agree, you want to talk to high, medium and low supporters to get a good map.
For one I worked at, I deployed receptive.io (now part of Pendo) and it showed every customer demographic wanted a specific feature and ALL their great ideas where shit on by the users.
The echo chamber at C level is, imo, the reason PMs get sidelined.
> The echo chamber at C level is, imo, the reason PMs get sidelined.
I spent a lot of my time at my last job trying to ascertain the business value of strategic projects - for which there appeared to be no business cases - while explaining to my end users who had strong businesses cases why their projects wouldn't be completed any time soon. Eventually it became clear that I was supposed to just make up some numbers to justify the work on the strategic projects; business value be damned. C level sometimes forgets their big ideas have enormous opportunity cost involved, and that they, too, should be able to justify the EFTs.
I spent a lot of my time at my last job trying to ascertain the business value of strategic projects - for which there appeared to be no business cases - while explaining to my end users who had strong businesses cases why their projects wouldn't be completed any time soon. Eventually it became clear that I was supposed to just make up some numbers to justify the work on the strategic projects; business value be damned. C level sometimes forgets their big ideas have enormous opportunity cost involved, and that they, too, should be able to justify the EFTs.
There's a moderately interesting cultural divide between "engineers must talk to customers" and "engineers must not talk to customers".
I've seen "must not talk" with a product owner who served to represent the voice of the customer, and incidentally take credit for the work he didn't understand and somewhat obstructed.
Also the same setup in prototype form where I couldn't talk to customers but also there wasn't a shim layer so I guessed what they'd want. That org has now converted to the former setup.
In the current one I don't talk to people who buy our tech but I do talk to their engineers. That gets rather direct feedback on what isn't working, facilitated by both sides improving the same codebase courtesy of open source.
Agile probably had the right idea in that engineers blocked from customers are more likely to build the wrong thing, and sales teams are right to be mistrustful of how the engineer may phrase descriptions of the system.
The open source backchannel collaboration seems optimal for me, at least in the niche where both sides have engineers employed working on the same codebase (llvm in my case but I doubt it's unique).
I've seen "must not talk" with a product owner who served to represent the voice of the customer, and incidentally take credit for the work he didn't understand and somewhat obstructed.
Also the same setup in prototype form where I couldn't talk to customers but also there wasn't a shim layer so I guessed what they'd want. That org has now converted to the former setup.
In the current one I don't talk to people who buy our tech but I do talk to their engineers. That gets rather direct feedback on what isn't working, facilitated by both sides improving the same codebase courtesy of open source.
Agile probably had the right idea in that engineers blocked from customers are more likely to build the wrong thing, and sales teams are right to be mistrustful of how the engineer may phrase descriptions of the system.
The open source backchannel collaboration seems optimal for me, at least in the niche where both sides have engineers employed working on the same codebase (llvm in my case but I doubt it's unique).
> I've seen "must not talk" with a product owner who served to represent the voice of the customer, and incidentally take credit for the work he didn't understand and somewhat obstructed.
The bits of Office Space with Tom Smykowski and the Bobs were funny when I first saw the movie, but as I grew older I realized their eternal truth: people hired as customer-engineer intermediaries (whether they're called "product owner", "business analyst", or anything else) get very tetchy when engineers start communicating directly with their user base because it threatens their job security.
The bits of Office Space with Tom Smykowski and the Bobs were funny when I first saw the movie, but as I grew older I realized their eternal truth: people hired as customer-engineer intermediaries (whether they're called "product owner", "business analyst", or anything else) get very tetchy when engineers start communicating directly with their user base because it threatens their job security.
> people hired as customer-engineer intermediaries (whether they're called "product owner", "business analyst", or anything else) get very tetchy when engineers start communicating directly with their user base because it threatens their job security.
I think SMEs and startups should avoid hiring for this role altogether for this reason. The dysfunction it can cause is a great risk companies of this size don’t need to expose themselves to. It leads to bad requirements gathering, designing the wrong specifications, and unnecessary work and communication.
I think SMEs and startups should avoid hiring for this role altogether for this reason. The dysfunction it can cause is a great risk companies of this size don’t need to expose themselves to. It leads to bad requirements gathering, designing the wrong specifications, and unnecessary work and communication.
> Unfortunately, [engineers] are not usually very good at thinking about the people who will use their systems, taking their preferences into account, and treating them like customers who they are trying to keep.
That engineers are all bad at people, have no interest in helping users has many visible obvious manifestions. But wow, I've grown really really tired of this kind of infantalizing dreck. I'd way rather try to find healthy & balanced engineers than work with anyone with this kind of "piss off engineer, we are the real channel to truth & value here" shitshow attitude.
Engineers often have a much more nuanced, complex, & advanced bead on what is possible, where to shoot for, & why it's good than product people. This downtalking article telling us we're bad at making useable things & that we need to change everything is part of a long long long line of corporate hierarchy games & clutching to power.
Edit: fwiw, most of the advice I'd grade as "not bad". But omg please never ever couch it like this.
That engineers are all bad at people, have no interest in helping users has many visible obvious manifestions. But wow, I've grown really really tired of this kind of infantalizing dreck. I'd way rather try to find healthy & balanced engineers than work with anyone with this kind of "piss off engineer, we are the real channel to truth & value here" shitshow attitude.
Engineers often have a much more nuanced, complex, & advanced bead on what is possible, where to shoot for, & why it's good than product people. This downtalking article telling us we're bad at making useable things & that we need to change everything is part of a long long long line of corporate hierarchy games & clutching to power.
Edit: fwiw, most of the advice I'd grade as "not bad". But omg please never ever couch it like this.
The "they" in that sentence refers to "infrastructure organizations", not to "engineers".
The post then points out that hiring Product Managers is not a silver bullet, and that a wider cultural change where engineers talk to end users is required. Which seems to be pretty close to what you're arguing for.
The post then points out that hiring Product Managers is not a silver bullet, and that a wider cultural change where engineers talk to end users is required. Which seems to be pretty close to what you're arguing for.
I'm doubtful that product owners are net positive. The idea that they'd be mistaken for a silver bullet is surreal.
Yes. The article is indeed talking about a pretty specific subset of companies.
"Adding product management to more traditional software infrastructure organizations, sometimes with a shift towards platform engineering, is all the rage today."
"Adding product management to more traditional software infrastructure organizations, sometimes with a shift towards platform engineering, is all the rage today."
Because I'm only working with software engineers and PMs I didn't read the article that negatively. I believe that when a product becomes big enough or its user base becomes large it can be very hard to empathize with all your different kinds of customers and external users, and therefore it pays to have a dedicated function (PM, PMM, designers, researchers etc) that can help with that process. It also pays to have a dedicated groups who can help be a more central point for creating a coherent product roadmap (which everyone of course feed requirements into (and engineers help scope, rank etc.))
Totally agree with you on this one, though I am in the unique position of building a tool for engineers. If anything they more careful and considerate than commercially minded folks who just want to ship features.
Yeah, w/o the engineers own desires there wouldn't be any open source community, or for a more fitting example of knowing what people want: Adblockers.
I read that as "engineers, who otherwise would be the greatest customer advocates, are horribly mismanaged."
Automattic (WordPress' parent company) has their engineers do customer support 1 month a year. Helps them understand people and their problems. And so far WordPress has come to become ~50% of all websites on the Internet, 30% of all ecommerce sites (through WooCommerce). And individuals, small and large businesses alike run things on WordPress without disruption and backwards compatibility problems for a decade and more now. Leave aside any evil like the "We are just 'deprecating' this on your face" that comes from the likes of Google and kills people's businesses.
So it can be done. Engineering cant exist for the sake of itself - if there is no one or nothing using the engineered system, than the system is meaningless. And without understanding those who use the system, engineering fails.
So it can be done. Engineering cant exist for the sake of itself - if there is no one or nothing using the engineered system, than the system is meaningless. And without understanding those who use the system, engineering fails.
> Unfortunately, they are not usually very good at thinking about the people who will use their systems, taking their preferences into account, and treating them like customers who they are trying to keep.
Then give developers a little more respect and let them do that!
It is telling that the longest chunk of this text is about not hiring too many PMs and the next longest is about better support. Maybe we should hire fewer product mangers and more support^H^H^H^H^H^H^Hcustomer success staff.
Is this a PM telling us why we shouldn't hire for that function? I agree and I'll vote this submission up!
Then give developers a little more respect and let them do that!
It is telling that the longest chunk of this text is about not hiring too many PMs and the next longest is about better support. Maybe we should hire fewer product mangers and more support^H^H^H^H^H^H^Hcustomer success staff.
Is this a PM telling us why we shouldn't hire for that function? I agree and I'll vote this submission up!
More support, better support training, and policies that don't handcuff their dispute resolution options (before lawyers get involved). Excellent support, and even taking it on the chin when appropriate, will do more for a business' image than any finely-tuned damage control press release.
[deleted]
Thinking of in-house software as a product is not all that useful. It's not a product. It does not have real pricing. You can't sell more of it and increase the customer base. You can't drop money-losing products. Cost centers do not have the same incentive structure as profit centers.
Here's a classic memo on that subject.[1]
[1] https://www.fourmilab.ch/autofile/www/section2_40_3.html