The aim of this article is to help the B2B product managers to get ready for the release of the new version of their app.

 

One of the main advantages of working in a B2B company as a Product Manager is that one can get very high-level feedbacks from customers within a short period of time. One can deliver a beta of the product and run tests with the support of your project managers.

 

1 – A beta is a must.

 

When?

A beta version is the best way to test your app. You need to release a beta at least 2 months before the official release. I would recommend three beta releases before the official release. It will demonstrate to your beta users that you are cautious and careful.

 

To whom?

Work closely with your project managers in order to select the beta users. For the first beta release, I would recommend tech-friendly users who use your app on a daily basis. However, it does not mean that you do not need to involve non-technical user – they have a major role from the beginning of the process – but it means that you should release a beta version to them only when you have got rid of the critical bugs. Otherwise, it can jeopardize the adoption of your app even before the official release.

 

MDM

You also need to select users who are using Mobile Device Management (MDM). An MDM is used by large companies to manage their mobile fleet. It can block some of the plugins you use. Otherwise, an MDM is a nightmare for the QA team. The beta is the only way to get ready.

 

The release of the beta

Organizing a beta version is a long process, try to not underestimate the time it takes. And do not forget that you will need to find a solution for iOS devices. It differs from the Android devices where you just have to generate a .apk folder. You will need to set up TestFlight for the iOS beta release.

 

Thanks your beta users

Don’t forget to thank your beta users. Take the time with the dedicated project manager to answer all the requests and control the bugs they signal. Keep them informed about the evolution of the bugs they identified.

 

 

2 – Freeze your code.

 

 

“No new features” … That’s not so easy to say in a B2B company

You need to be very careful about the tickets you are creating in the backlogs of the developers. Starting a new feature for your app a few weeks before the official release can be risky. This is one of the most difficult tasks for B2B managers. Indeed, your work is driven by new features because clients are paying for that. On one hand, you cannot say no to a new feature which can lead to a big contract. On the other hand, creating a feature might mean adding plugins and modify the existing components. In other words, changing your code a few days before the release.

 

Before starting a new feature, we always check the business case, the scalability of the feature, the risk and compatibility with our strategy and vision.

 

I would recommend taking only highly valuable projects within the two months’ period before the release of your software and to freeze your code (your master branch) at least two or three weeks before the release.

 

Outsource tests

Between the 8th week and the 2nd week before the D-day, your main focus should be to test your app. The hundred devices you might have in your office are not enough. If you have an E2E QA team it is wonderful (automated test). But I would recommend outsourcing some of your tests to specialized companies as Applause, Testbirds, Test IO, … Be ready, it takes time, you will need to write dozens of manual test cases with your QA team. Ordering exploratory testing cycles is not enough.

 

Don’t ask too much to your developers

Remember, the pre-release period is one of the worst periods for your developers. They are not working on new features. They are only fixing bugs all day. Even if you are under stress, don’t be rude or too demanding. It is your role to help the lead developer to prioritize the treatment of the bugs. Take the necessary time to explain the issue, to analyze its impact and to make the tests together with them. You need to act fastly, if it is a major bug, don’t wait for the fix to be pushed before testing.

 

As a technical product manager, you are not allowed to blame a developer to have broken the code while he/she was fixing a critical bug for you. You and the QA team have to ask the good questions to the developers in order to list the potential impact that each change might have. You are the one who knows the app and who should understand the impact of each change you made in your app.

 

Check my former article, Leaning to code, a real asset for product managers.

 

3 – Communication is key

 

Project managers are under pressure, help them!

As a product manager, you should be confident. All your changes have been made by analyzing data and collecting feedbacks. You have an amazing design, developers and QA team who worked during months with you in order to make the life of your user easier with this new version.

 

But it won’t impede that the project managers and the support team are stressed by this new release. It will have a big impact on their clients and they are under massive pressure.

They will come up with a lot of questions, make sure they are well framed. Never be rude. They are no stupid questions. Remember that there are one of the best assets you have for the success of the release. They are the bridge between your app and the client.

 

Check the setting of the permissions of the users.

A new version of your app means new features and a new design. It means you have to review your offer and your package with the product marketing team and the executives. Moreover, it means you have modified the permissions’ users for your app. This is crucial, you need to create proper documentation for your project managers. They will have to double check all the permissions of their clients’ users. It is a long process and it has to be done as swiftly as possible.

 

 

Sources: