Agile was becoming a norm for software product development and everyone gives it a high priority as a project management method. The essence of Agile is constantly adapting your plan and products so that they fit customer and business needs rather than because ‘that’s what it says in the plan’. Its emphasis on customer satisfaction and speed-to-market are big pluses that product teams everywhere have come to take for granted.
But when your customer isn’t the end user, things get more complicated. I wanted to share some of the lessons that I’ve learned along the way.
The beauty of Agile is that it allows you to adapt. In b2c you release often and can react immediately if things don’t go to plan or if you spot a new opportunity. But in b2b you need your customers to adopt a product before it even reaches the end user. That makes product management a very different beast; you don’t get the instant gratification that comes at the end of a b2c sprint and you face a lot more uncertainty.
So it takes discipline, expertise and an unusual amount of planning to get the most from Agile methodologies with b2b products – but it’s worth it. If you’re driven by reach of impact rather than instant success and you enjoy a challenge, then b2b product development is a fascinating place to be. Patience is a key personality trait for b2b product managers.
We work with a variety of businesses, and we have to be flexible in how we collaborate. Some of our customers also use Agile practices, but we work with some partners whose dev cycles can be up to two years ahead. That might seem at odds with Agile methodology, but it’s a simple fact of b2b product management. In fact, the flexibility of Agile often means we’re able to surpass our customers’ expectations. When we’re planning with them, we can only promise what we know for sure will be available at a certain point in the future. But the ability to react constantly, rather than stay tied to a long, fixed roadmap means that, when we get there, we’ll often have developed new products and functionality that neither of us could have foreseen.
Other times we’re able to work closely with partners on a specific feature, even carrying out beta testing with select partners. Communication between your own teams becomes vital here. In b2c, market research can tell you a lot about what your users want. That kind of data is not always available in a b2b setting, so it’s important for us to talk to our customers. This often means our account managers keeping an ear to the ground or canvassing customers on their product needs, and talking to the technical team to scope the opportunity. When we do carry out beta testing, selection is key. You often have to plan months ahead, and choose a partner that can work on the same timescales and understands that they won’t be working with a final version.
The travel industry was an early adopter of technology, but we’re still constantly innovating
Of course you can’t do every sprint based on a specific want or ask. Bespoke functionality is not always an option for large b2b teams. But a direct ask that has wide applications can be useful – you know you have a willing partner that wants to test out a feature, and you can involve them in discovery and beta testing. Early partner testing like this is great in b2b, where you often don’t have access to data on the end user. Then again, we may develop a new feature that we’re sure will have wide appeal and then work with our sales force to find partners who we know will benefit.
The complexities for product managers are much bigger in b2b, so communication is key
Whether it’s internally or with the customer, communication is fundamental to being Agile – and in b2b, where you have more touchpoints and stakeholders, it’s especially important. In part 2 I’ll look at the importance of minimizing those handoffs, and why product teams should be Agile evangelists.