You are the king or queen of the product. You’re the engineer, the designer, the business mind, the marketer… in fact, you are a little bit of everything. You are the product owner, but more importantly, you are the leader.
In his article, Prasad Thammineni (CPO of Choose Energy) outlines the 9 qualities of a great product manager:
To embody these 9 principles, you’ll typically see PMs use a myriad of tools to organize teams, manage development, QA, and track benchmarks (JIRA, Aha, Mavenlink, and about 10,000 others). Every aspect of effective product management seems to come with its own suite of tools, but two areas are generally lacking: Customer Empathy and Customer Feedback (interviews, testing), which I’ll explore in greater depth.
As a Product Manager, you must empathize with the needs and wants of your target audience. As Catherine Shyu (PM at FullContact) writes:
“The product manager is responsible for knowing the customer like the back of their hand — their frustrations, their daily thoughts, the context in which they use the product, and their needs.”
It’s one thing to ask your customers for feedback, to interview them during development, and to have them test your product before it’s launched. It’s another thing to have your customers test your product in a real environment or to provide certain customers with a personalized experience.
A key to empathy is the ability and capacity to take action on feedback. As Jennifer Winter notes,
“Collaborative and creative empathy doesn’t equal sympathy. The goal of empathy is to support and understand the intent and purposes of others, which in turn will help you obtain insightful feedback.”
User interviews, in-person testing, assigning tasks, and conducting basic user research are fundamental to developing a successful user experience. However, they each have a common limitation: artificial feedback.
When we sit down with a user and ask he or she to do something, we have taken that user out of their natural environment by forcing them to unnaturally provide feedback. The feedback we receive is still valuable, but it’s not purely genuine.
Genuine feedback comes from testing real users in a real environment without them knowing they are being tested. Imagine being able to test a new feature or experience on 1% of your actual users before launching to the other 99%.
For example, I could release Feature A to 1% of my users. If they never use the feature or only use it once, then that feedback is deafening. Now, imagine if you could just roll back Feature A completely and then use interviews/testing to figure out why the feature wasn’t being used, and then roll it out again.
Feature flag driven development enables this genuine feedback loop.
PMs at Google, Facebook, and Amazon have integrated feature flags into their development cycle. This allows them to gather user feedback on a feature before it has been fully released. It also helps them be more responsive to feedback without having to leave a “bad feature” out on the market for too long.
Let’s say Facebook wants to release a new timeline feature called Timeline Beta. This feature reorders timeline stories in order to increase user engagement. Let’s also assume that Timeline Beta has gone through all the rigors of internal testing, user interviews, and whole gamut of proper UX research.
For launch, Facebook wraps Timeline Beta in a feature flag, allowing Facebook to have complete control over who sees the feature.
On day 1, they roll out the feature to 0.5% of Facebook users to see how they like it.
On day 2, they see a 20% decline in user engagement for those users who had Timeline Beta.
So, on day 3, Facebook rolls back Timeline Beta via the feature flag and begins the cycle anew.
Imagine if Facebook released Timeline Beta to all of its users without an easy mechanism to revert to the previous version. They could have seen millions in lost revenue, caused a social media uproar, and turned users away. This is the power of feature flag driven development: the ability to take full control over feature releases and test features in a real world environment.
Product managers have enormous responsibility. They must coordinate multiple teams, identify business objectives, manage timelines, and take ultimate responsibility for the success of a release.
Luckily, integrating feature flags into a development cycle does not require a complete process transformation or months of retraining. If you’re already practicing continuous delivery, feature flagging can become an integral part of your dev cycle in no time at all.
If you’re an agile team, then you can think of feature flagging as a way to iterate safely and intelligently, without the risk of crippling your application or upsetting all of your users. This is what allows product managers at top companies (Facebook, Google, Amazon) to safely manage the product lifecycle and gather genuine user feedback.
Thanks for reading! I love writing for you, so claps and follows are greatly appreciated :)
Create your free account to unlock your custom reading experience.