RARELY SAY YES TO FEATURE REQUESTS
RARELY SAY YES TO FEATURE REQUESTS
中文概要：
- 这个功能是否符合您的vision
- 这个功能5年后是不是一样重要
- 是不是所有人都会从中受益（这点很关键。越来越多的人或者人们正在逐渐忘了软件存在的本身是在为了解决某一类问题，是在为用户提供服务，而不是一味关注KPI,闭环）
- 新功能会对现有工作流有一个提升、补足或者创新吗？
- 能不能增长business
- 加入该功能后会不会形成有意思的内部竞争，会不会有联动作用
- 如果该功能被证实是一个很棒的功能，我们有能力实现一机维护它吗？
- 付出与收获平衡吗？
- 我们能够做好这个功能吗？
- 我们能否很好的审视我们的产品
Here’s a simple set of Yes/No questions that you can quickly answer before you add another item to your product roadmap.
Saying yes to a feature request – whether it’s a to an existing customer, a product enquiry, a teammate, or a manager – is immediately rewarding. It’s an unspoken transaction where you barter[易货贸易] long term product focus in exchange for short term satisfaction. Buying short term joy for the cost of long term pain is the human condition.
Previously we’ve written about how product strategy means saying no, but a list of reasons to reject a feature isn’t as immediately useful as a test that any new feature must pass. Lots of our readers made that exact point to us too:
So here’s a list of questions your new feature must score straight yes’s on.
1. DOES IT FIT YOUR VISION?
More important than any metric, customer request, or sales target is your vision. What do you believe that no one else does? What do you know about this problem that no one else does? How do you believe it should be solved? Anyone can pull the data, run the focus groups, read the Gartner reports, get out of the building, but only you have your vision.
Product decisions based on vision alone sometimes seem irrational[不合理的], because they’re tough decisions. Most people understand that their bug tracker doesn’t also monitor server uptime. That’s rarely debated, it’s not a marginal call. But should a project management tool have a reporting feature? Not so clear.
The more nuanced[微妙的] decisions are the ones where you meet resistance. Colleagues, customers, even other product managers and founders will push back. Here’s some examples.
- Garrett Dimon refuses to add an “on-hold” state to his issue tracker, Sifter, as he simply doesn’t believe it’s the right way to manage issues.
- Apple refused to ship netbooks at a time when netbooks were the most popular style of PC. Every analyst demanded them.
- Basecamp refused to add Gantt Charts. For that they were labelled[贴上标签的] blind ideologists[思想家]
Worse than being a hard decision, you’ll never truly know if you got it right. There is no right. There is no wrong. This is art, not science. It’s just you and your vision.
2. WILL IT STILL MATTER IN 5 YEARS?
There’s nothing like the immediate gratification[使人满意之事] from jumping on the latest trend. Twitter cards, Google Glass Apps, apps for wearables, Facebook apps, some new JavaScript effects library – it’s all crying out to be used. It’ll make you feel modern.
It’s a hard and boring question to ask but will this still deliver value in five years time? You’ll feel like the curmudgeon[吝啬鬼；存心不良的人] of product planning. But that app that was so hot in 2013 was gone by 2014. Those slide, fade, and fold effects that everyone loved last year look tacky[俗气的] as hell this year. If you’re going to spend the best years of your life on a product eschew[避免] the trendy, and focus on the meaningful.
3. WILL EVERYONE BENEFIT FROM IT?
Beware the “fre-cently” bias[偏见]. You assume the things you hear frequently or recently should without doubt be road-mapped. It’s a natural reaction caused by your inbuilt empathy[移情作用；执着] for customers. It’s not nice to tell people “no” repeatedly and hear the same responses over and over, so when possible “fre-cently” is used as an excuse to reward yourself. “Sure we’ll build that, I’ve heard it twice today already,” says the founder with 4,800 daily active users, to the unbridled joy of 0.0625% of her customer base.
The danger of the fre-cently bias is that it gives you the illusion[幻觉] of analysis, the sense that you’ve done your homework and this is a rational conclusion you’ve come to. In reality you’ve made a lazy decision to satisfy the whims[虚妄] of a small sample of vocal users without taking a second to investigate how many people really want or need the feature.
4. WILL IT IMPROVE, COMPLEMENT[补足] OR INNOVATE[创新] ON THE EXISTING WORKFLOW?
Adding a whole new workflow to your product should be a rare occurrence. The majority of your time should be invested in improving, complementing, or innovating upon existing ones, and for any given project you should know which of these you are doing.
If you’re improving the current solution, your metric will be customer satisfaction and/or maybe a decrease in tool time, or support requests.
If you’re complementing it, your metric will be an increased throughput[生产能力] for the workflow as it now works in more cases or can be used in more circumstances.
Innovation is the trickiest[复杂的]. You’re shooting for the mythical[虚构的] “whole new way”, which carries so much risk but offers so much reward. Your measure will likely be new customers acquired though often they come indirectly, as a result of the PR, marketing or awareness created.
Redesigns are fun, but you can spin your wheels on them. A good way to cut through the bullshit is to simply ask “Will more people use it? Will people use it more? If neither, then will it definitely be better for those who do use it?”
5. DOES IT GROW THE BUSINESS?
Can you join the dots between the impact this new feature will have and new revenue[收益]? In the example above the company makes the case for project templates, the argument being that templates can be used in more cases, which should increase the number of projects customers have, which in turn increases upgrades, and thus revenue.
Note that reducing churn[搅动，变动] also grows the business; dollars don’t care where they come from. Often a feature is added to ensure stickiness of customers, or to widen the moat[壁垒，护城河] around a product. The key point in all cases is to understand how any work affects growth, after all everyone works on growth.
6. WILL IT GENERATE[形成] NEW MEANINGFUL[有意义的] ENGAGEMENT[交战，诺言]?
Most metrics ignore the system and focus on the isolated feature being added. Put a new button in your product and people will click it. Get enough clicks and you can call that an increase in engagement. But that’s nonsense. **A counter-metric is “have people stopped doing anything else**”. So if you add a metric to track one area of your product, you must also analyse the other areas that are likely to be impacted.
A real world metaphor[隐喻] is the effect of “Diet Coke with Lime[石灰]” on Diet Coke sales. We see how launching a whole new workflow affects sales. If you’re the PM on Diet Coke with Lime, you could call your launch a success, but if you’re the CEO you’ll realise you complicated your product line, bought all these limes, all these juicers, and all that advertising, and have no new revenue to show for it. Not exactly a success, no matter what metrics that PM can show you.
7. IF IT SUCCEEDS, CAN WE SUPPORT & AFFORD IT?
One fallacyp[谬论] of “quick wins”[速效方案 快速致胜] and “easy hacks”, is they usually only evaluate effort required before shipping e.g. someone surprises you with a JavaScript bookmarklet for your app, or an agency produces a Windows Phone app in record time and low cost, and because the effort was relatively minimal, and the idea makes sense, you ship it. Success!
Then the support requests come in, and it turns out none of your team know XAML, so you’re stuck with a broken build live, and a few hundred customers complaining to support about it. Of course it’s never that obvious. Good engineers rarely say they don’t know something, they’ll hack at it some evenings, display some initial competency[能力，资格], and then estimate[估计] how long until they fix the bug. This is all time that you didn’t plan on spending when you shipped this app. And that estimate is wrong. And then some.
Another area that can bite is offering incentives[激励], or initiatives that you can’t justify. If you have a CMS product, and you offer free homepage designs, you’ll get more sign-ups. It makes sense to do this early on, when you really need to entice customers to try an as yet unproven product, but it won’t work long term. It goes without saying that doing things that don’t scale is a great strategy, until you scale.
8. CAN WE DESIGN IT SO THAT REWARD IS GREATER THAN EFFORT?
As Paul previously wrote, for any feature to be used the perceived[感知] benefit has to be greater than the perceived effort. End users understood the benefit Google Plus could bring, but the overhead of dragging and dropping many copies of your contacts into various boxes, on a regular basis, was simply not worth it. I feel that check-splitting apps habitually fall into this category. Splitting a check can be a pain point, but any solution seen thus far still costs too much, and we’re not talking about price. We’re talking about time, overhead, social capital, etc.
Product design is about cost-benefit analysis. How useful is something, vs how hard is it to do. Here’s how I think of it…
It’s important to know which quadrant[象限] you’re designing in and if you’re wise you’ll steer[控制] clear of the upper left for all but the most essential of features.
9. CAN WE DO IT WELL?
Every product has its neglected corners, usually areas where the PM dabbled[涉足] but conceded[给予] defeat. Conceding defeat all too rarely results in removing a feature, it usually just means ignoring it, leaving a messy trail and a confused offering.
The problem here is when product teams tackle areas they don’t fully understand. This is often the case when a team moves beyond self-design, that is, past the point where they are their customer. At this point their design process breaks, and they need a new one. Examples include:
- Teams that don’t track time adding a time-tracking feature
- People who don’t manage calendars designing a calendar management option.
- Designers who don’t close issues building an issue tracking system
Note that none of the above are inherently wrong, what’s wrong is the design process. It needs to move beyond “works fine for me” into something much more activity focussed. To build a feature well, you have to understand the job it does intimately[熟悉地]. As a corollary[推论] to the old saying: if you can’t do it well, it ain’t worth doing.
10. CAN WE SCOPE[审视] IT WELL?
Starting with the cupcake release for a feature is essential. Early usable releases provide the feedback necessary for an idea to flourish[繁荣]. A good sign that a feature isn’t well scoped is when it lacks specifics[细节], e.g. “Make it work for bigger companies”, or that it’s feature based e.g. “reports”, as opposed to job-based e.g. “Let sales managers see their team performance”.
It’s always easy to agree on truisms[老生常谈；老套；众所周知；真实性] in product meetings. Someone says “It should be easier for bigger teams”, everyone nods, and a Post-it gets stuck on a whiteboard. It’s only in the specifics that you’ll understand the scope e.g. “we should let people group their colleagues by department” vs “we just need an enterprise mode”.
Badly scoped features meet no ones requirements, ship late, if at all, and add nothing to the product but confusion.
SLIPPERY[狡猾的；不稳定的] SLOPES[斜坡] & MARGINAL[临界的；末端的] CALLS
It’s tempting[诱惑人的] to excuse occasional violations[违反，妨碍] of this list, assuming that “as long as it’s right most of the time”, it’ll be fine. Maybe that’s true in theory, but this is software. Reality bats[怪异的；疯疯癫癫的；神经不正常的] last here. This is why we say that product strategy means saying no. Roadmaps are incredibly hard and require agonising[烦恼的] trade-offs, but regardless, every good product manager needs a firm checklist for when they say yes, and when they say no. And they don’t make exceptions.
Products get bloated[发胀的，浮肿的；傲慢的] one lazy decision at a time. There is no single choice you’ll make where some light turns on saying “Your Product is Now Too Complex”, and you’ll never get an email saying “Last Thursday at 2:03pm Your Product was Disrupted[破坏]”. Bloat, complexity, and disruption can only be seen in the rear view mirror, so always be mindful of the risk of saying yes.
Want to read more of our product best practices? Download our free book, Intercom on Product Management. It’s recommended by folks like Ryan Singer, Hunter Walk, and Dharmesh Shah.