When you’re a small startup – let’s say below 12 people – you’re one product team. One of the co-founders is almost always the lead product person. They make the calls, the chain of command is clear, and all is relatively easy. When your company scales past 40ish people, things change. You’re likely to start hiring product managers – that is, people whose job is to run certain areas of your product. As the founder, you’re no longer directly in control. There’s someone else sitting between you and the designers and engineers making the magic. This, it turns out, can be a very confusing transition for both the founder and the team.

When Meebo made this transition, I did what most founders do, I held onto minute control. This expressed itself in the dreaded “drive by.” Yep – I repent my sins – I was that guy. The “you’re doing it your way until the founder does a drive by and tells you to scratch it all and do it a different way” guy. I can only take solace in that many an entrepreneur I chat with reports suffering the same affliction.

Many of you reading this are shaking your head, knowing full well how disempowering this behavior is. To make it explicit, let’s say you were working on a project and would, randomly, get told to do it a different way. What would you do? You’d probably abdicate control. You’d probably stop thinking creatively. Stop being proactive. Rather, you’d wait to be programmed by the next drive-by. This, folks, is not good for the health of your product.

The irony, though, is that it’s incredibly important for the founder to stay deeply involved in product. We all hear the stories – the moment the founder leaves is the moment the startup goes into decline. The best products are often created with a singular vision. That person of course takes input, but they’re the editor. And thus, you don’t wind up with a lowest common denominator solution.

Back to Meebo. I started to hear that my drive-bys were causing problems. I heard it from my co-founders, Elaine and Sandy, who saw the effects first hand. I heard it from my spies deeper in the organization (always have spies!). Eventually, my reaction was to pull back. I could see how my behavior was disempowering, so I chose to give people full ownership. They would own the product. I’d provide advice and guidance, but would rarely absolutely force a particular solution. I’d give them a way to think about the problem, not a solution. But in retrospect, that was a step too far. The singular vision and all the benefits from it began to slowly erode.

But then it clicked. I came upon a way of managing product where the founder maintains product direction, even at quite a detailed level, without disempowering.  It turns out it’s all about cadence of feedback and expectations. Here’s how to do it:

Once you have a PM or two, you likely have multiple areas of the product you pay attention to. For each area of the product, set up a weekly meeting with you, the PM, the lead engineer and the lead designer. Don’t make these too frequent – twice a week at most early on in a product lifecycle. Probably no less than every 2 weeks for a more mature product. In these meetings, you have free reign to give very detailed feedback. “This is a great start, but I don’t think the user’s will understand this flow,” or “the overall feel is great, but this button needs to be bigger – guide the user to the action we want them to take.” You can get quite detailed. But then when the meeting’s over, it’s over. No drive-bys, no random comments. Wait for the next one. The only exception, of course, is if the team proactively comes to you asking for guidance. I’d suggest settings up twice weekly “office hours” as an open forum for these types of questions.

Managing this way, your team feels real ownership. Between meetings, it’s their job to move the product forward. They come up with new ideas; new solutions. A fleshed out flow. They own it. But of course, like in any organization, they get feedback. This feedback comes at defined times – and at those defined times they know they’ll be getting feedback. But because it’s expected, and they own pushing the product forward, they don’t feel disempowered.

There are a number of edge cases to watch for. Eg, if you find yourself dramatically altering the team’s approach at each of your review meetings, something’s wrong. The team will begin to feel disempowered – they’ll feel like they’re not able to make progress between meetings. You need to diagnose these edge cases as they arise. In this particular case, it’s likely that you’re not giving the team enough directional guidance at your checkin meetings, thus they’re going in a direction you’re not comfortable with.

That’s it – a simple way of managing product that keeps your team happy and healthy, while keeping tight rails on product. I know this, to a founder, can sound scary. Waiting a week to give feedback – to move the product forward – feels like an eternity. But the rewards are significant and your product will be better for it. If you’re not already on this system, give it a shot, even with just one of your product teams. The results will surprise and delight you and team alike.