Building Global B2B Products : Can You Ever Be “Truly Agile”?

Right off the bat — I believe the answer is that “true agile” development practice works only partially in a B2B software product company. With “agile” being generally understood as focusing mainly on “now” and not having much visibility into the future with more specific estimates. This is due to the specifics of customer acquisition and overall behaviour of B2B segment, which I’ll talk about in this article.

Differences of B2B and B2C Product Adoption

Before going into the details of B2B product development, I’d actually like to start from the other end — the cost of B2B software adoption and the cost of switching software. I bet you don’t think about these two numbers much when planning your next big B2B idea but the truth is that they significantly impact your plans and the way you develop.

For an average B2C product (e.g. task management mobile application), the cost of adoption is extremely low. It used to be higher but since the dawn of app stores and new, simple programming languages there are literally thousands of options to choose from.

As a consumer, I’m only one tap away from installing different application and entering my first tasks. If I don’t like what my particular application does, I can simply uninstall it, open app store again and in less than a minute have a brand new tool at my disposal.

The learning curve of B2C applications is usually not very steep since B2C product teams often build their product to be used by almost everybody and don’t expect users to have any specific skills. Nobody is going to read your documentation, regardless of its comprehensiveness. If the end user doesn’t get what your application does in 1 minute, you are out.

Now, B2B products are a completely different story. As we already discussed in one of the previous articles, the purchasing process of enterprise software usually takes many weeks/months and involves lots of people of different seniorities.

Long story short — it’s very expensive. Companies are investing lots of resources into the selection process because they know the true cost of enterprise software isn’t really the license for the tool itself, but the training and adoption of users within the organization.

Regardless of all your awesome product features, unless somebody trains your new client users how to use the product, it will not be used. Enterprise users are often missing the intrinsic motivation to adopt your product — unless it’s something very close to their heart. This is especially true for products that are not directly related to users’ day-to-day jobs.

Example: Building HR Software Platform

Let’s say you are building HR software platform. It supports onboarding of new employees, vacation planning, internal education, recruiting and an internal job market for people to move around inside the organization.

It’s fair to assume that, once you sell your product to a new company:

• That company will have to invest significant resources just to set it up and integrate with all existing databases/internal systems (Single-Sign-On, employee database, recruiting channels)
• The company will have to train all employees on how to use the platform since everybody will have to go in there once in a while (at least to book vacation)
• The company will have to update all internal documents/employee handbooks/guidelines to reflect the new reality of digital HR processes and consistently maintain them as your product develops
• Depending on the complexity of your platform, the company will have to give the entire HR team (and possibly even payroll and finance) comprehensive training on every module you offer, plus keep them updated as you ship new features

After they’ve done all this (it’ll take weeks, if not months for bigger companies), imagine your competitor comes to pitch their HR platform and is smartly focusing on “three features” (= product value) that’s unique to their product AND for a 10% lower price than your product.

Do you think your customer will jump the ship?

Very unlikely. If your product costs them $X, the process of selecting it and implementing company-wide adoption has likely cost them $10X and they are not going to go through the process again unless:

• You don’t talk to them and ignore their needs for a substantial amount of time
• The competitive product is significantly more valuable
• The competitive product is significantly cheaper

Simply said, once a B2B company selects your product, they are in for the long run. Even further up-sells need to be planned well in advance due to fiscal years, budget plannings, etc. The company needs to be absolutely sure they are buying the right tool for their current + foreseeable short term needs.

For all the reasons described above, it’s very common to receive this question from prospects:

“Can you share your product roadmap for the next 3/6/12 months with us?”

Now what does this have to do with the agile product development process? Everything.

Having “a fixed plan” vs. Being “Agile”

In true agile culture, you focus on minimal viable products, A/B feature testing (ideally live on customers), shipping value fast and possibly even making mistakes (that’s when you build products that don’t stick and customers don’t adopt). It also means that you need to be able to change ideas fast based on what works. In most cases, you think mostly short-term and don’t plan that much in advance. For that reason, agile companies (usually B2C) are able to share what they are currently working on and then list ideas they want to explore “later”.

If you ask the company either:

When is feature X that you’ re working on going to be “done”?

OR

Approximately, when will idea A be implemented into the platform?

they will not give you any specific answer simply because they don’t know.

In agile culture, the definition of “done” is very questionable (a topic for its own article) and since you only know the scope of a feature MVP, you won’t know how much time you will need to possibly follow up on its success and further development.

The situation could be especially problematic if the scope of the development changes rapidly based on instant feedback from the feature’s initial users. When enterprise companies sign 1–2-X years long contracts for B2B products, they simply need to have some visibility on approximate product plans, at least on a quarterly basis.

Nobody says you have to commit to a concrete release date for a specific, often just vaguely defined, feature, even though this is also common during early startup days in an attempt to win the first big customers. However, you should be able to explain your product vision & the specific steps needed to get there + approximate timing at least 3–6 months ahead.

Continuing our example: Adding a feature to our HR Platform

Let’s have another example from our imaginary HR platform. Your agile development team is working on new feature — the integration of a recruiting module directly into LinkedIn. They have a clear scope of the MVP and share its release date with the sales team. Once released, the feature immediately catches the interest of some of your existing customers and they start enquiring about further development and using the feature heavily. In the B2C world, you would simply follow the crowd and continue building this module but in B2B the situation isn’t as black and white.

You might have already promised other features to other customers. Some of them might not be at all interested in your LinkedIn integration but truly need a better permissions system for the entire application. You know the “MVP” of permissions won’t cut it because it’s a mission critical application and even the initial scope will take at least 3 months of work.

What do you do? Tell the other customer(s):

“Sorry, but we are not going to develop permissions anytime soon because this LinkedIn thingy seems to be interesting”

or will you simply ship LinkedIn and potentially come back to it 3 months from now if it’s still relevant? That’s the life of B2B product management team.

So how do we do it @ Socialbakers? :)

I work at Socialbakers where we deal with these kind of situations every day. We have the privilege of building global SaaS products with the help of several product development teams, who we manage. Apart from feature research and preparation, one of the most important responsibilities of my product team is communication with our internal colleagues (mainly sales) and, of course, customers.

We have a clear 3–6 months roadmap where most of the features take ± 2–3 months of development before being released to customers on production. The development itself is managed in SCRUM framework: plannings, groomings, retrospectives… all that fun stuff.

The development is as “agile” as it gets in the context of what I said above. Features are developed live in a DEV environment and as soon as it’s functional, we release it to a few selected BETA customers before the full “general availability” release.

This process works well in general, apart from occasional changes to planned release dates (given changes of DEV team velocity, unforeseen user stories, etc.) and to the follow-up communication chain that both internally, and externally to the customers.

Do you have a better way to rapidly build and test B2B products? Do you even use roadmaps with dates or do you just have two columns “Now” and “Later”? I’m interested in your methodology and would appreciate you sharing your feedback below in the comments.

Thanks for reading!

And don’t forget we’re hiring! I guarantee that building a fantastic product is even more fun than reading about it.