“I feel like the product team is in a silo”
This is one of the most common points of feedback I heard from customers and colleagues as the Chief Product Officer of the company I co-founded, and I recently heard it again from the founder of another product company. I want to walk you through each side’s perspective here, because they’re all valid.
From the non-product-team perspective (generally customers and non-technical employees), an R&D department can look like a black box. A customer submitted a feature request – what happened to it? Finance just became aware of a $25,000 engineering spend, seemingly out of nowhere. Sales heard about that cool product we’re working on – are we able to sell it yet? To the rest of the organization, the product team can feel siloed and distant. Yes, awesome new products come out and can drive growth, but the cadence seems lumpy and unpredictable. When Product is asked to explain something or give an update, we get buried in details, 80% of which we can’t even understand. It’s opaque, frustrating, and feels apart from the rest of the organization. Why does Product get to be so mysterious? Ops isn’t allowed to do that!
From the CPO’s perspective, there’s a bunch of conflicting forces at work. Customers are asking for features, but some of them are conflicting (Customer A wants X, and Customer B wants the OPPOSITE of X). Or the feature request is straightforward, but it’s backed up behind an internal project you can’t share with customers. That $25,000 spend was sudden because there’s a new regulatory requirement that applies to a 5-year-old product that’s been doing just fine, but now we have to overhaul some components to be compliant. And the classic Sales / Product tension – R&D is scared to death to tell Sales anything because last year they pitched a customer on a product that was still under development – in this case, the black box is intentional. Lastly, things feel lumpy or overly detailed because to Product, you live or die by the details. We may have been 90% done on a project to find out the last 10% misses the mark and we need to take 2 steps back down to 60% and re-build. To everyone else that felt like “Wait, yesterday you were 90% done and now you’re saying it’ll be 6 more weeks?” When you explain why with technical detail, eyes start to glaze over.
Here’s the punchline: both perspectives are 100% right, and a ton of time is wasted trying to “get the other side to see the problem”. The situation between the departments is the problem, so it’s very hard to see, and easier to say “if Finance knew what a mess this compliance thing could have been, they’d be thrilled we only spent $25k”. The solution here is to solve at the root, and the root exists at the intersection of all these.
Below are some frameworks / tools you could cheaply and easily employ to solve this at the root. I’d hate to say it, but this is squarely the job of the CPO (or any product leadership title) to implement. That’s not a placement of blame – it’s because the transparency needed can only come from the leader.
Fix #1: An open backlog that is prioritized. At first, this makes most product folks I know shudder – stick with me here. First, this does not have to be some complex new tool or crazy hosted website – candidly, I just used a Google Sheet and people loved it. Next – the key is to put all the requests in here, things you’re working on that you are able to share, the bugs, etc. – put it all there. Also have a “completed” section so folks know what you have done. Lastly, do not put a timeline to all of this. It’s about prioritization – people want to know what you’re working on now, and what you’re working on next. This gives everyone else visibility on where their thing stands, and you the flexibility to allocate resources appropriately. The only thing you’re committing to is that you’ll prioritize and work on them in that order. You should be doing this, anyway. Want a ready-baked, simple-to-use template complete with automations? Here it is:
Fix #2: Set priorities for every 90 days so everyone knows the “big projects” Product is working on – only between 3-7, less is more. EOS gives you this automatically with Rocks and the Quarterly Planning. Between this and Fix #1, everyone now knows what you’re working on today, this week, and this quarter.
Fix #3: Master The Transfer. Again, people over complicate this. Focus on the 20% that gives you the 80% gain. There was a time at my company where every transition from R&D -> Operations required an 8-page Engineering Change Notice document. As a result, nobody did it. Remember the basic principle of what a handoff is trying to communicate: “We in R&D think this product is ready for the next stages”. We just used an email template. Could be Slack. It covers the basics: here’s what we built, here’s when we’re ready to launch it, here’s what Sales/Marketing needs to know, here’s what Ops needs to know, here’s what Finance needs to know. That’s it.
Now take a step back and look at how this all maps out. First off, the 3 tools I listed above can be implemented in less than 2 hours of work – because they’re not complex or difficult – they’re just a habit. So the easier it is to get started, the faster it will stick. Next, let’s revisit the common issues we covered above. Customers now see where their requests are, and more satisfyingly, also get to see the stuff that’s already completed (Open Backlog). Sales gets to see what’s coming, and the rule is simple: feel free to look and get excited, because it’s exciting…but don’t sell anything until we completed The Transfer. Finance may not like the $25k spend, but it no longer “came out of nowhere”. And lastly, as the CPO, you won’t have to give nearly as many of those forced “status updates” where you feel the need to dig into the details – most communications in this new setup will be high-level.
If you’re continually hearing about “the silos” in your company, I can show you the path to making operations so smooth you can focus on growth again. Let’s get on a call and tackle this.