Some coffee-thoughts on various product-y buzzwords

• Non-Feature Teams. Dividing up the company into 1) product/feature teams and 2) “operations” (or backend teams, or infrastructure) creates a false dichotomy. Behind this decision is invariably a bunch of assumptions baked into the org chart and how teams are funded. These assumptions are rarely challenged, and they should be. The under-funded “cost-centric” teams struggle, get demonized, and just say **** it (eventually). They go into survival mode.
• Products and Customers. To get any attention, departments start calling things “products” that aren’t even products, and start referring to internal partners as “customers”. On one hand this is good — they’re thinking about value, viability, and opportunity — but you run the risk of NOT mapping activities to real customers. And you risk all the local optimization that comes with kingdom building and drawing boundaries around things.
• “Product thinking” is great…and potentially dangerous. My take is that products are a value delivery mechanism. To deliver value you need a “who” with goals and needs. The trouble is that teams fall in love with their delivery mechanism of choice (their “solution”), and lose sight of the big picture. Once the organization incentivizes individual products to close a $ amount — unless these products are completely independent — you’ll see all kinds of anti-patterns emerge (in addition to the behavior you’re looking for). Product thinking is helpful when viewed as an antithesis to “project thinking”, but has a lot of baggage in complex ecosystems.
• Expansion and SKUs. The central assumption behind SaaS companies is that they’ll leverage their customer base for revenue expansion. This inspires “multi-product” strategies whereby there are more SKUs to sell. You can only raise the price on the “original product” so much, even if it is insanely valuable and is massively under-priced. But are these things actually products? Or are they packages? A GM and product manager do not a product make, especially when these products are heavily integrated into other “products”, and share target customers/users with similar needs and goals.
• Layers and Layers. Every silo you create in your organization will require another layer of management and coordination to buffer the inherent selfish interests of the “part”. I hate when “product” is just shorthand for “agenda”….and that’s what you see.
• Product? Solutions? Pay attention to the various ways SaaS companies struggle with this push-pull between outcomes (e.g. things like “Explore”, “Engage”) and the need to sell more stuff, please investors, and figure out how to structure their product development efforts. There’s always a weird kind of Conway’s Law and Reverse Conway’s Law in effect.
• Buying Revenue. Acquisitions…the eternal juggling act. Do you “fold them in” quickly, or let them “be independent”. Same goes for speedboat teams exploring new product ideas. It is so hard to avoid the BIG MISTAKE…whereby people rationalize all kinds of economies of scale and synergies that fail to materialize. The Synergy Trap is real. It embodies a laundry list of cognitive biases. I can’t count how many times I’ve heard — a year later — “oh, well, we didn’t take into account [some unique characteristic of the acquisition (or innovation effort)] and tried to impose [some global process] because we thought it would make things easier!”
• Convergence. You enevitably see a swing back to “Omni-channel” as the company realizes that the customers/users are overwhelmed. Customers/users don’t care about your org chart, and they get bored and tired of being pitched things. “Help us get our work done! If I see one more pop-up in the product I’m going to cancel!” Internal things start to explode as well. “What are we actually selling?” “Do I get commission when they expand?” “What new shiny thing should I sell to hit my quota?”
• Legacy Product. And woe is the “legacy product”…that stalwart that raised the money, launched a bunch of happy customers, accumulated a bunch of technical debt, and still hums away month after month earning the bulk of revenue. You have so much domain expertise nested there, but the org has shifted focus to shinier things. The irony….the shiny things were what the legacy teams were imagining the whole time…they’re just too constrained.
• Converge/Diverge. You can view this shift back and forth between inconsistent and consistent experiences as a natural ebb and flow. We diverge to innovate, and then converge to “fold in” that innovation. We tactically accept duplication and messiness, because without it we’d get nothing done. That said… there are “right” and “wrong” ways to embrace duplication and messiness. Consider the companies that replace “the monolith” with a bunch of shoddily designed microservices. Suddenly they have a load of spaghetti microservices and shit is exploding. Is there a net-benefit?
• Consistency is easy…just throw a lot of people and process at something. But that type of consistency comes at a deep cost. Scaling is fundamentally a question of what must remain consistent, and what we spend/lose/sacrifice to achieve that consistency. So in this back and forth between convergence and divergence you see a lot of attempts to “force” consistency, or stand back idly as teams struggle with a sort of wild-west, dog-eat-dog battle with chaos. Neither is all that productive in my opinion. Some consistency may be valuable, so the trick is figuring out how to achieve it with the least amount of drag and downside. Doubling the “height” of an organization isn’t my first choice…nor is hiring teams of project managers. Too costly.
• Pricing Example. A great example of “cheap” consistency is figuring out a simplified pricing model that 1) customers love, 2) maps to what is actually valuable, 3) is “simple”, and 4) scales out with new value added services. This is hard to do, but oh so effective when you nail it.
• Levers. So… in closing. Yes, by all means embrace “product thinking”. But keep in mind that products are delivery mechanisms that link an actor with an outcome. The customer/user doesn’t care what you call it. You’ll always have these levers of centralization/decentralization, convergence/divergence, control/novelty, etc. to play around with. But realize that we’re naturally wired to assume things that don’t pan out.
• Customer/Team Centric. Finally… keep an eye out for when you’re optimizing for internal “business” needs (or personal agendas) over the needs of your teams and/or customers. You can absorb a fair amount of chaos when there’s trust. The stability that comes with working in little kingdoms is comforting, but it may not be the best way forward for your customers. Your most passionate employees will quickly sniff out the incoherence. The fictions you create internally (e.g. “products” and “departments”) may have no resonance with the people doing the work and the customers consuming the service to get their work done.