Makin' Money, Savin' Time: Guardrails Not Guidelines

Some will probably say this crosses the line between product and delivery. No lies detected. But as I told a client yesterday, "If someone else wants to do the work, I will gladly let them. But if no one is, and it needs to be done, I’m going to get it done." That is the kind of product manager you want. No excuses, just results.

One of the four values of agile is individuals and interactions over processes and tools. In fact, it is the first value listed in the manifesto, yet many companies put heavy emphasis on consistency and streamlined processes. Entire roles are created to enforce them. Sure, streamlining to an extent makes sense. But it’s often overdone, and the implications are costly, confusing the ability to produce meaningful results. It’s far more important to define the guardrails that matter and let go of the guidelines that don’t produce value.

In one of my product roles, we had implemented SAFe six months earlier, delivery slowed tremendously, and teams were at odds. I had been analyzing our processes and interactions, researching different frameworks, and I kept coming back to the same conclusion: my teams and their work were best suited for Kanban.

So when our program leaders requested that we pick up the pace, as if it was our fault things had slowed down, I was ready. I felt confident they would love the idea of implementing Kanban. Instead, they hated it. They raised a long list of concerns and shut it down. I took their feedback, created answers to each concern, and met one on one with a key program leader to earn her buy‑in. Then I went back to the broader group, presented a compelling vision with answers to their questions, and the key leader voiced her support. With that alignment, the program was finally willing to try.

Once I started working with the team, the positive changes were immediate. The team was noticeably happier. Honestly, if that had been the only outcome, I would have considered it a win. But the results went far beyond morale. Six months later, feature cycle time was cut in half. The team delivered 25% more features each quarter. Tool adoption started to increase again. I kept stakeholders and the program informed in a way that met their needs, and the team kept focusing on delivering high value. Our business partners fawned over how quickly their needs were being addressed.

I still can’t help but smirk when I think about a conversation with one of the program leaders after I presented our success to the department. He asked me, “Shouldn’t we make everyone do Kanban?” to which I replied, “I think you might be missing the point. We weren’t successful because Kanban is a one size fits all solution. If it were, it would be the only framework. It worked for us because our work, our team mentality, our strengths and weaknesses were a perfect fit for it. And you allowed us to try it. The other teams need the same, space to find what works for them.”

In the spirit of makin' money, savin' time, I bring you to this conclusion. Companies build entire roles and layers of process to create the illusion of control, but all it really does is slow teams down. You end up paying more to get less, adding friction and reducing clarity. Most organizations don’t even realize they’re doing it. Don’t let it be you.