Good product improvement requires figuring out and homing in on the magical overlap between desirability, feasibility, and viability—the place innovation lives. Product managers are consistently within the place of getting to defend the stability amongst these domains, countering the forces that compete to tug a product too far in a single path on the expense of the others. This implies saying no—many instances and to many individuals—over the course of the product improvement journey.
Earlier in my profession, I labored on a undertaking within the automotive area, creating an app that used machine studying knowledgeable by environmental information and person habits to offer sensible options to drivers. On the time I joined the workforce, the app was poised for launch and administration was wanting to launch it, however I quickly realized that it was removed from prepared for manufacturing.
Whereas the app was visually interesting, a number of the most basic design questions had been ignored, comparable to “What downside are we fixing, and for whom?” and “How determined are folks to have this downside solved?”
The app boasted a function that might show the climate on the driver’s vacation spot. From person habits and site visitors information, the algorithm may infer the place a driver is perhaps headed and the way lengthy it will take to get there, and a easy climate API integration confirmed the climate forecast for the vacation spot on the time of arrival. This appeared like a pleasant use case, however in actuality, nobody cared. After I performed my very own person analysis, together with a paid survey of European drivers, the response was a convincing “Meh.” That’s arguably the worst suggestions you will get: It means your product solved an irrelevant downside and signifies that the desirability dimension is extraordinarily low. Viability is then a misplaced trigger: It’s unattainable to construct a viable enterprise with a product nobody desires. We needed to scrap the entire thing.
How may this have occurred? The reply is difficult, however it boils right down to the truth that a vital phrase wasn’t uttered when it ought to have been: No.
The corporate’s core competency and belongings have been machine-learning inference engines and extremely scalable structure design. The top of knowledge science was a robust stakeholder who wished to see his inference engines put to good use in a buyer software. His affect, partially, had resulted in a product that was fully tech-centric. Growth had been pushed by what was possible technologically as an alternative of what clients desired.
It appeared that no person had instructed this stakeholder no, and if that they had tried, it hadn’t been efficient.
Product Technique Means Saying No
Saying no is difficult. Folks don’t at all times like listening to the phrase, and there may be typically a worry that saying it’ll injury necessary relationships. As product managers, relationships are central to our position, however so is guaranteeing that our merchandise are profitable and stay in stability.
So, how do you reject somebody’s request whereas preserving the connection intact? I like to recommend these practices:
- Set your self up for achievement.
- Don’t say no too rapidly.
- Reframe the request.
- Encourage a local weather of contribution.
Set Your self Up for Success
On the outset of a undertaking, it’s important that everybody agree on a shared imaginative and prescient for the product’s success (“Why are we doing this?”) and on a set of metrics that can be used to measure progress (“How will we all know if we’re doing it properly?”). In case you don’t agree on what success seems to be like, it’s solely a matter of time earlier than conflicts come up.
It’s useful to make use of a framework to doc targets and map them to one thing measurable. I like to make use of a free model of Google’s HEART framework, which organizes person expertise into classes for Happiness, Engagement, Adoption, Retention, and Job Success, after which articulates targets, indicators, and metrics for every of these classes. Objectives tackle what you are attempting to realize, indicators break down every objective into person actions, and metrics monitor these actions to gauge the way you’re doing in a method that’s quantifiable.
On one latest client app undertaking, I wished to conduct a restricted pilot to find out if customers discovered our prototype helpful and wished to maintain interacting with it; I used to be centered totally on the Engagement class of the HEART framework. I then needed to establish indicators and metrics to trace progress towards that objective:
- Aim: Customers need to work together with the app and proceed utilizing it.
- Sign: Customers open the app steadily.
- Metric: Proportion of customers who open the app not less than twice per day.
This strategy of figuring out and aligning on targets might seem easy, however it’s not simple. On this case, it concerned calls with the consumer and our gross sales workforce, impartial analysis, and a number of workforce workshops. Based mostly on the knowledge I gathered from this discovery, I used to be capable of current the finished HEART framework throughout the kickoff assembly with the consumer. We went by all of the objects and tailored the place wanted.
Making certain that each one stakeholders are concerned within the goal-setting course of is vital, and getting everybody to agree on what indicators and metrics must be tracked eliminates the necessity to say no repeatedly as a undertaking progresses. It additionally provides you information to level to if somebody approaches you with a request that falls exterior the parameters of the plan.
Don’t Say No Too Rapidly
Even when key stakeholders agree on what success seems to be like and the highway forward appears clear, one factor is definite: Somebody, someplace, will method you with an unexpected ask.
When that occurs, don’t say no too rapidly. Even should you’re sure the request is unreasonable, rejecting it outright shuts down dialog and will injury the connection. It additionally undermines the product discovery course of. As product managers, we have to see the total image, and listening to individuals who disagree with us reduces our blind spots.
You possibly can nonetheless say no, in fact, however you might want to keep away from knee-jerk responses. These result in binary discussions which are the results of black-and-white, right-or-wrong, win-or-lose considering: Both you implement one thing otherwise you don’t.
To maneuver towards more practical, nuanced discussions, you might want to set up requests in response to the agreed-upon standards you’ve established as a part of your goal-setting course of.
As a substitute of asking a stakeholder “Is that this function invaluable to you?” ask “How invaluable is that this function to you?” The ensuing dialog ought to provide the data you might want to collaborate on an inventory of “desires,” ordered by way of significance. It’s important that this rating vary from 1 to n, with out permitting a number of objects to share the identical place within the hierarchy. This offers everybody a voice within the prioritization course of and excuses you from having to reject requests unilaterally. Some requests will fall by the wayside when the group downgrades them in favor of extra necessary ones.
Reframe the Request
A request that appears unreasonable initially can yield constructive outcomes with some refined reengineering. First, pay attention to what’s being stated. Actually pay attention. Put your assumptions apart and attempt to perceive the place the opposite individual is coming from, after which discover widespread floor. In case you dig a bit of deeper by asking “Why”—not essentially the 5 instances you’ve heard about; two to 3 will usually suffice—you may unearth an element that speaks to a shared objective.
Even a superbly smart request can profit from a deeper dive and little bit of reframing. I keep in mind a scenario wherein I used to be engaged on a enterprise intelligence instrument for a B2B mobility service. My consumer requested me, not unexpectedly, to get subscriber numbers up. Whereas the motivation for rising the variety of paying subscribers could seem self-evident, I wished to ensure I had the total image, so I requested, “Why?”
It turned out that the product in query was approaching the top of its life cycle, and my consumer wished to squeeze out the final drops of revenue earlier than changing it with a brand new product. With this data, I reframed the request to “How may we significantly enhance income within the quick time period whereas laying the groundwork for the upcoming product launch?”
In the end, the perfect resolution was to not trouble with subscriber numbers in any respect however to raised align pricing with worth. Clients had been paying a hard and fast month-to-month subscription, no matter how typically they used the instrument for rider transactions. The extra rider transactions they processed, nevertheless, the extra worth they derived from the instrument. Clients ranged from particular person taxi drivers making solely a handful of month-to-month transactions to multinational freight carriers—with dozens of subsidiaries and 1000’s of autos—making a whole bunch of 1000’s of month-to-month transactions. The identical mounted month-to-month subscription was too excessive for the small shoppers and too low for the large ones.
By making small pricing changes, we elevated income whereas baby-stepping towards a tiered pricing construction (primarily based on variety of transactions) for the soon-to-be-released product. The brand new mannequin diminished the worth for many clients whereas rising it for the largest clients, who had been benefiting disproportionately.
By reframing requests on this method, you’ll be able to create win-win conditions. The individual bringing ahead the request feels heard and revered, and also you acquire perception that may add worth with out derailing the product improvement course of.
Encourage a Local weather of Contribution
One of many largest dangers of claiming no is that rejections can undermine the spirit of openness and collaboration that you just’re making an attempt to foster, each inside and out of doors your workforce. Concepts encourage, whether or not or not they develop into related, and the very last thing you need to do is stem the move of creativity and communication.
I as soon as labored with a junior QA engineer who had a wealth of concepts. At almost each assembly he requested a number of questions and volunteered options. His options have been typically not actionable ones, and a few of them may have been dismissed as unhelpful or irrelevant. However his dedication and enthusiasm have been invaluable. He was completely invested in delivering the very best product, and his contributions energized and impressed others. An perspective like that’s contagious.
You need to create an surroundings wherein folks really feel inspired to share ideas and concepts, and are rewarded for doing so. Your workforce ought to be motivated by the potential for enhancing issues as an alternative of discouraged by the considered being dismissed, ignored, or ridiculed. Implementing a number of easy practices might help make sure the psychological security of your workforce.
Acknowledge concepts and requests publicly. This builds belief and reveals that you just worth options and are dedicated to contemplating them. Arrange a request field, or a Confluence web page or different public discussion board that each one stakeholders can entry. When a request is available in, log it and ship a message to the requester, thanking them for his or her contribution.
I do know this will show controversial, however I generally go so far as to open the product backlog to everybody. This may be notably useful in fostering engagement from the product workforce, in addition to permitting workforce members like QA testers and designers to notice issues they’ve encountered. The principles are easy: Anybody can add to the finish of the backlog, and through refinements (or different weekly conferences) workforce members share what they’ve added and clarify why. Solely the product supervisor can change the order of points or delete objects. Many individuals assume that granting everybody this stage of entry will result in chaos and anarchy, however it doesn’t. I’ve tried this at organizations of various sizes and it solely fails when individuals are too shy to contribute their concepts.
When you’ve applied an answer or launched a function even roughly associated to one in all these logged requests, credit score the requester publicly. That is particularly necessary when the answer will not be a transparent success of the unique request however extra of a reframed model. Exhibiting appreciation for everybody concerned in successful creates goodwill, builds camaraderie, and encourages folks to proceed taking part.
Weighing the Execs and Cons of Saying No
In case you take the time to essentially pay attention and perceive the place stakeholders are coming from, you hardly ever have to reject proposals outright. Lively listening, clear communication, and mutual respect are key elements in dealing with requests which will initially appear problematic or out of scope. Most instances, the artwork of claiming no by no means truly includes saying “No.”
There can be conditions wherein it proves unattainable to search out widespread floor, and a direct no is required with the intention to shield the product and the undertaking. In different circumstances, chances are you’ll be compelled to comply with by on belongings you don’t agree with. As a lot as your job is to guard the stability of desirability, feasibility, and viability, there’s a fourth dimension to think about: pragmatism. To maintain issues shifting ahead, compromise is essential, and generally which means avoiding a no altogether.
The fantastic thing about Agile product improvement is that its iterative nature presents many alternatives for course correction. In any case, the objective is build-measure-learn, not debate-dispute-derail.
