Why aren’t you delivering new functionality without telling everyone beforehand?

This week it struck me that although I’ve worked in quite a few different companies, almost all of them make a huge deal of delivering new functionality. Most companies put a lot of time and effort into planning. They create gantt schemes with clearly defined deadlines, list of features in a backlog and as they approach a release they ramp things up even further. Endless time is spent on documenting each feature, sessions with affected departments are scheduled and at some point you’re probably losing track of why you’re doing the things you’re doing. And in the end, we’re never sure if anyone became any wiser from all of these activities.

At the same time, I see many of my favorite products continuously launch new features without finding the need to tell me beforehand. Why is that?

Expectations (and mindset) differ between companies

The first reason is because not all companies are built the same or have the same expectations from their users. Let’s say you’re a bank with an online and mobile bank service. The majority of your customers are simply interested in having services that work and they don’t always appreciate a new user interface or feature. Even if a majority of the customers like the change, some companies find a way to focus on the minority who don’t. A natively digital company will probably have a completely different set of demands from their customers. The reason you chose to use that service in the first place may have been the superior user experience and clean interface. In that case changes are not only welcomed but expected. These companies typically have a different mindset as well, where they are used to shipping new features on a regular basis and use data to validate their assumptions.

So if you're working within Product, you need to understand the desire of your users and balance that against what the company wants to achieve. Depending on the change you’re doing or the feature you’re shipping, informing the user in some way may be needed to not impact the customer satisfaction negatively. But it’s also to overrate the interest customers have in the change you’re working on. A platform change or launching a new system of some kind may be important internally but have limited value for the customer.

Lean on your research and optimize for the desired outcome

One of the main pitfalls when it comes to releasing new functionality is the lack of outcomes connected to them. Most companies are simply content if they manage to release something at all or meet the oh-so-important deadlines set by management. If you don’t understand why you’re doing something it’s hard to know if you’re reaching the desired outcome. If you instead do your homework and put time into research and discovery, you’ll have a more solid hypothesis of why this new functionality is needed and if it takes you closer to your overall strategy and goals. If the data then confirms your hypothesis, you won’t get caught in worrying about a few complaints. Instead you’ll be happy that you’re one step closer to fulfilling your strategy and moving the company in the right direction.

The release itself can never be the goal you’re aiming for, instead worry about what problem you’re solving for the users and ensure you’re doing that instead of stacking up release documentation. If a company doesn’t work with outcomes, it’s easy to think that the release of new functionality failed because a couple of users or employees complained about the lack of information or documentation beforehand.

Use the product yourself and create the right culture

An old truth within some of the companies I’ve worked with is that employees need to be informed of all changes beforehand. If not, how could they possibly serve the customer in a good way?! Well, if you establish a culture where your own employees are experienced users of your products, they’ll easily pick up any updates or changes made to the product. This is of course not applicable to all situations but if you create a culture where everyone in the company actually use and experience the product on a regular basis, you will create greater awareness and minimize the need for time-consuming documentation and information overload.

When we talk about creating the right culture within a company, what you also want to see is a company where there is trust in the product teams and their ability to make the right decisions. The people screaming for information prior to a release are not always those who need to face the customer, but rather stakeholders who lack faith in the teams.

If you’re struggling with this, a first step could be to set up company-wide demos or similar forums which anyone can attend to get the word out. This will probably help you increase the awareness of your product and greater transparency which could help you calm stakeholders. There will definitely be situations where the actual product limits this, for example if the product is aimed for specialists or experts. In those cases you won’t really be able to become a familiar user yourself and if that’s the case you will probably need to find other methods to create awareness and transparency.

Find new ways to inform users and involve the right people early

In companies where there is a big emphasis on compliance and legal aspects, you’ll often see plenty of documentation produced before the release of new functionality. You’ll expect to see a detailed list of the changes made, maybe some screenshots of how it looked before and after and in some cases long meetings where a Product Manager has to go through that same information. The idea here is maybe to create a sense of inclusion but in most cases what you achieve is a ton of documentation that probably has a limited effect.

Depending on the product you can try other methods to inform both your users and employees of new features. Do user testing to see if you can nudge them into finding new functionality and use data to see if you actually managed to sway users into trying it. What you should also try is to involve people from departments such as Legal and Compliance early on in the process to ensure transparency and a greater sense of involvement in the process.

Today many companies are disappointed when they fail to popularize new features but they look in the wrong direction for answers. The answer is probably not more documentation but rather designing for specific outcomes and then using actual data to understand if you’re getting any closer. The principle build - measure - learn can be applied to documentation as well. More is not always more so instead of focusing on creating a false sense of urgency by increasing documentation, understand what your users need and how you can help them get there while keeping documentation to a minumum. You can even go so far as to remove all release documentation and see how people react, if at all!    

Föregående
Föregående

Lessons from a year in SAFe: Don’t fixate on roles, look at teams’ maturity

Nästa
Nästa

Guide i skillnaden mellan Product Manager och Product Owner !