Release planning best practice #1: Separate soft and hard launches

Release planning is always beholden to the development process, which can be unpredictable. When things don’t come down the pipeline as planned, marketing is left wondering what’s going on (and their budget might take a hit, too).

One key to successful planning is to separate the soft launch and the hard launch for any software release. In effect this is separating the project management of the app release from the project management of the marketing release.

When the time comes, the “hard launch” of this feature is just a matter of pressing a button to remove the flag in the app. And marketing knows they can confidently move forward with their side of the plan.

Release planning best practice #2: Adopt a release train cadence

When a train comes every 20 minutes, you’re less stressed about missing it than if the train comes once every two hours. The same is true in release planning.

The release train process sets a frequent pace for routine software releases, prioritizing development work over deadlines. Whatever development work that’s 100% ready will go out. If you miss one, no biggie! There’s another release coming up soon. This week’s release might be just a few bug fixes, next week’s might be huge features. 

When releases are less frequent, developers might rush a specific project so it makes the release date, for fear of getting in trouble. They’re under tight (and often arbitrary) deadlines with high stakes, and that’s stressful! This leads to lackluster code and technical debt.

Instead developers should approach their work thinking, “Let me get this to a quality that satisfies the requirements with good code.” With the release train cadence, developers might spend a little more time and deliver stuff they’re proud of. If the feature doesn’t come out today, that’s fine. It will come out tomorrow.

As for cadence, the more frequent, the better. The quicker the pace, the less pressure on each individual task, developer, and release. This could be every day, every week, or whatever is reasonable for your team.

With this method, your product is constantly getting better and it’s no stress for developers or users. 

3 steps after a release goes live

Successful release planning doesn’t end with the launch. Just like in baseball, basketball, and golf, follow through is important if you want to hit your target outcome.

These three steps are my recommendations to ensure not only a smooth product rollout, but also a healthy work culture where each person feels their time and effort are valued. Taking care to touch base and show appreciation are key to a high-functioning, happy team—both within product development and across the company!

3 common mistakes in release planning

In the first section, I already went in-depth about the mistake of tying release planning to development planning. Finally there are a few other mistakes that many product teams make, all with the best intentions! 

2. Prematurely committing time or scope to any release

In project management, there’s a concept called the “iron triangle.” It represents the limited resources of time and money, and how those affect the scope of the project (and vice versa). When one element is squeezed or maxed out, then other parts break.

With product releases, more often than not, quality gets squeezed. And this is how you get technical debt. Developers launch crap after crap and then two years later, they quit (the stressful launches might have something to do with it), and the entire codebase needs to be rewritten. Every company does it!

For more thoughts on the subject, learn how to build a release plan that everyone understands

The post Planning for Success – How to Master Release Planning appeared first on ProdPad.

User personas: fictional or not?

We all know that “personas should be a fictional representation of your users”. This line was even used by our CEO, Janna Bastow, in her article: How to Work With User Personas When You’re a Product Manager. But unfortunately it’s a line that can be easily misconstrued. People often just make up a character based on their own thoughts and say they have a user persona. 

But for user personas to be truly valuable they must be based on real data – a summary of all your research and interviews. So while they should not be a real person they should be based on real data from multiple people, they’re a way to encapsulate and make that data easier to digest. To make user personas valuable, you need to speak to your users, learn about them, and turn that information into a persona type that reflects a real user.

It’s the work that goes into creating the user personas that truly matters.

Unimportant user persona details

People adopt a “real person” to make their fictional representation come to life, or to make user data easier to digest, but this is where most of my issues with user personas lie.

Giving the user persona a name makes it easier to remember, but how will knowing their age, sex, ethnicity, maritial status and whether they drink tea or coffee help me (or our designers) to create a better experience for them? As soon as you add such information into a user persona you leave it open to interpretation, assumptions and unintentional bias. Does it really matter what they drink or whether they are married?

Demographic factors like age, ethnicity and marital status should only be included if they have meaning for your product or if they affect the interaction with your product. Does it matter if your user persona is married? Does the info you include have deeper meanings and invoke more questions about your user? Ultimately demographics and stock photos just don’t matter that much (unless they have meaning to your product) – people spend hours deciding these small details or finding an image to use, when most of that information is useless. Unfortunately, most people fail to look beyond demographics which is where the key information lies. 

Different user persona types

There are many other types of personas: marketing and buyer, to name a couple. I often see that the lines between them are blurred, as people try to create a one-size-fits-all approach that ends up not being useful to anyone. They are distinct for a reason. Each of these personas or users has a very different goal, so you should keep them separate.

This is what had, unfortunately, happened to our personas at ProdPad – they had become a mish-mash of marketing and user personas, and it meant they were no longer useful to our product work.

Created and never touched

“The important part about personas is to remember they are meant to be living documents. As you learn more, update them so they don’t become outdated assumptions, but realistic representations of your users.”

Janna Bastow, CEO and Co-founder of ProdPad

I couldn’t agree more. Time and time again, user personas are created to only be stored in some GDrive folder and never used. At best they’re presented to the wider team, turned into beautifully printed artifacts and stuck on a wall, never to be touched again.

The “never to be touched again” is the key issue here. At ProdPad we had fallen into this trap. User personas should be driven by your users. Just as your product matures and grows over time, so does your user base. We’re all in the habit of updating our product regularly as we learn more about our users and their needs, but the user personas are forgotten. There is no point building for your user base of five years ago – it will look very different from where you are today and the direction in which you’re headed.

How can user personas become a useful asset again?

If user personas fail, it’s usually down to the way that they’re implemented. There are a few tricks and must-dos that can turn them into a valuable asset, not only for your day-to-day product process, but for the whole organization, improving collaboration and understanding across teams.

It’s all in the groundwork

The key is in the groundwork – learning and listening to your users. I’m a big believer in all PMs having regular face time with their users (as Teresa Torres outlines in this post about  continuous discovery) but I am also well aware that this can be a luxury. If you’re a PM who can’t get face time with users, then speak to your customer-facing teams. They will have a wealth of customer calls and demos that you can draw on to learn all about who your users really are, and you can use that as your baseline. If you haven’t talked to anyone, then you can’t rightly create a persona to represent them.

I’ve been in the fortunate position of being able to speak to our users every week for the last six months (and it’s something I will always do) so I had a huge base of data and insights to draw from when it came to reevaluating ProdPad’s.

Better together

User personas on their own are just one facet of your user base. They are at their most powerful when combined with other data available – namely customer and market segment data. There are so many dimensions to a user. If your user base is anything like ours then you’ll have  behavioral personas (hopefully) as well as role types, plan types, industry types, team size and many more. All of these other data points are very valuable in understanding a persona’s context, but with such a broad user base, they often can’t all be given equal importance at once. User personas, combined with customer and market segments, can really help you drill down.

At ProdPad, I created a matrix that outlined all the different dimensions our users can have, helping me to make sense of the characteristics and contexts that I’ve come across in my research. Just knowing and splitting out behaviors and contexts was enough for me to create a persona. I didn’t then need to weigh it down with extra details in an effort to make it more human – the traits I had identified could belong to anyone, regardless of demographics.

I then mapped initial behaviors and contexts to some of our customer data so I could look at the types of account and job roles that would be likely to inhabit those behaviors.

You’ll notice that there are comments in the above gif. This is where our product and our customer team came together to chat through my mapping. It meant that everyone bought into the user personas, and they became useful beyond the product team and across the organization.

It’s about behaviors and scenarios

In my opinion the “fluff” that surrounds user personas won’t help you to design a better experience, unless it’s critical to the product you’re building. Thinking about how your users behave and what they are trying to accomplish is the core of what you need to help you and your team align their needs. Kim Goodwin has written extensively about this.

This was the final part in the creation of our new ProdPad user personas. We added a very simple scenario to each behavioral type – for example, what are they trying to do when they come to ProdPad? That, combined with their role and behavior, has given us a strong grounding for our next set of user personas.

What’s next?

You’ll notice that our user personas don’t have names, stock pictures, or any demographic details. For ProdPad, the main difference between them comes from their activities and contexts.

We’ve now added these user personas to ProdPad. They’re useful to my work every day, allowing me to see trends on where feedback is coming from, what matters most to them, and where the holes are. More importantly, it’s given the product team and our customer team a shared language. We now have a set that we believe truly represents our current user base. When you’re building a product that must meet the needs of a diverse audience – with different use cases, goals, and scenarios, not different ages or ethnicities – your product needs to work, make sense and deliver a good unified experience to each of those different users. Having a shared language with the customer team means we can be aligned on whether we address all equally, or zero in on a primary audience first. That, for me, is where the power in user personas lives.

In the meantime why not log into your ProdPad account and have a go at setting up some user personas of your own. Not a ProdPad user? Why not start a free trial and see what all the fuss is about. 

The post Creating User Personas: A Product Manager’s Approach appeared first on ProdPad.