The smallest functional slice, avoiding the stomach ache

Building the best product org is not about using what works best for XYZ company. It’s about finding what works best for you, your team, and your product.

After last week’s post, “Product market fit, one slice at a time,” Russell, whom I’m connected with through a coaching group, brought to my attention some pitfalls of the smallest functional slice method. It would be wrong of me not to discuss these and some important considerations. So, this week, let’s look at ways to avoid those pitfalls with your teams. This goes beyond functional slicing and is more about culture and how to drive the behaviours you want to see more of.

Russell is an accomplished PM and former Director of Product. He’s experienced some of these challenges firsthand, so I appreciate him calling them out. There’s no easy solution, but we agree that having the right culture is important to making functional slicing work.

This post was originally published in my Substack Newsletter, Roadmap Weekly.

So, what can happen when you approach product development through the lens of functional slicing without the proper culture in place? Russel points out that there are two inherent risks:

1. Potentially overwhelming your product with technical debt and
2. Moving on to the next big thing without fully exploring the last thing results in half-baked features that work but don’t live up to their potential.

I’d say that both of these potential issues will lead to technical debt, but worse yet, #2 leaves you with a buffet of features, most of which no one wants, at least in their current state. It causes feature bloat, user confusion, support challenges, and lack of focus.

Building a culture that supports rapid iteration

Functional slicing can help you and your team deliver value to your users faster, but that alone won’t radically improve the product culture at your company. The absence of functional slicing could indicate a culture antithetical to functional slicing in the first place. So, before you explore this technique, some other cultural beliefs should already be in place or well on their way.

1. Desire to address technical debt and leave things better than you found them.
2. Be willing to remove slices (functionality) if it’s not what most users want.
3. A high level of trust between executives, product, engineering and even customers.
4. Iterative tendencies and a desire to go back and improve on previous functionality.
5. Clear strategy and roadmap for where your product needs to grow.

But Steedan, how do I build those cultural beliefs in my product org? Can’t I start functional slicing now? Sure, you can. You can implement these processes and change the culture simultaneously. In fact, you have to. After all, culture is how you do what you do. Granted, a lot can feed culture, such as attitudes, beliefs, organizational structure, etc., but a key strategy to improve culture is change management, which often involves processes and, when done right, can change the culture.

Reasons to avoid functional slicing

Functional slicing is critical to running your product organization if you’re following product-led growth, but it may not be as openly accepted when you’re building enterprise software or working in an area that requires high compliance and oversight.

Building the best product org is not about using what works best for XYZ company. It’s about finding what works best for you, your team, and your product within your own organization at the present time. That isn’t to say you can’t start to shift the mindset and implement new processes while you shift the culture around you; that’s what needs to happen as you implement change, but I’m not going to lie and say it’s easy.

Other benefits to functional slicing

The benefits of functional slicing reach far beyond product-led growth. You can gain many benefits by taking this approach, even in more traditional organizations and products. If you’re looking to make a case for a shift to functional slicing, I’m sure you can find even more benefits, but here are ten great benefits that come to mind:

1. Improved Focus and Clarity: Slicing work into functional units allows teams to focus on a specific functionality aspect, leading to clearer requirements and a better understanding of the task at hand.
2. Faster Feedback Loop: Smaller functional slices can be developed and tested more quickly, allowing for faster feedback from stakeholders or users.
3. Risk Mitigation: The risk is distributed by working on smaller functional increments. Issues can be identified and resolved earlier in the development process, reducing the likelihood of large-scale failures.
4. Better Prioritization: Functional slicing makes prioritizing work based on value, complexity, or dependencies easier. Your first iteration will give you real-world data that can be used to drive future product decisions.
5. Flexibility in Planning: If changes need to be made to the scope or direction of a project, it is much easier to adjust when working with smaller slices of functionality.
6. Simpler Testing and Debugging: Testing smaller, independent functions can be more straightforward than testing a complex system in its entirety. It also simplifies debugging, as fewer variables exist to consider when something goes wrong.
7. Customer Satisfaction: Regularly delivering functional increments to customers can increase their satisfaction, as they see continuous improvements and have opportunities to provide input throughout the development process.
8. Streamlined Deployment Pipelines: Functional slicing creates smaller, more manageable units that can be integrated and deployed rapidly. These rapid releases will drive teams to develop more streamlined deployment pipelines.
9. Enhanced Rollback Capabilities: If a release encounters issues, rolling back small functional slices is easier than with large super features teams spent months working on.
10. Facilitates Feature Flagging: Functional slicing is conducive to feature flagging, where new features can be toggled on or off without redeploying. This allows for more control over feature releases and can help manage user access.

If you’re looking for buy-in to try functional slicing, hopefully, some of these benefits will appeal to your teams and management.

Have you taken the functional slicing approach to product development? What lessons did you learn, and what do you think about this approach? Like everything in product management, it’s not a one-size-fits-all, but I challenge you to try it with your team if you haven’t already.

This post was originally published in my Substack Newsletter, Roadmap Weekly.