by Liraz Axelrad
When asked about the future of “Home” – Facebook-not-really-mobileOS-but-kind-of” Mark Zuckerberg said: “It’s a tough thing determining when something doesn’t work, and when something hasn’t worked yet”.
Indeed it is. And sometimes it’s up to us PMs to make that decision. Sometimes it’s our job to make the hard call; to call it quits.
An object lesson
A few years ago I worked on the launch of an outdoor portal. One of the features was advanced search. I was in love with it. It had so many fields! So many options! Using it, one could find exactly the right activity for oneself, or so I thought.
And then we launched it, and no one used it. Was it because the feature was simply not needed, or did we screw up the experience? Could we make it work? Was it worth our time? And mostly, how could I know?
The easy option was to keep the feature as is. Let it be. Do nothing, make no decision. As a PM, I’m short on time and resources and, well, it’s already there, right? Working and all. No harm no foul.
Only it ain’t so. Dead spaces in our apps are harmful. We should not let our apps become graveyards for failed ideas. Apps get inflated over time because we keep adding stuff to them, so it’s doubly important to trim them down whenever we can. And it’s also important not to be afraid to make the call.
The problem is, we tend to fall in love with what we do. It’s a good thing when we start. Our enthusiasm fuels our advance and the whole industry, for that matter. But it can become an obstacle later on, when things don’t work as we expected. At that point we should be able to make an informed decision.
Should we kill the feature, or iterate on it? That’s the question we need to answer. Those are our options. Now let’s make a decision. A few question to consider:
- What are the feature’s metrics and how do they sum up in comparison to what we promised at the beginning? How big is the gap?
- Do we have practical ideas on how to close that gap?
- What were our goals for the feature, what did we try to achieve strategically and is it still valid?
If the answers to any of those questions is “No”, then it’s a no-brainer, kill it. But If the answer is yes, then it’s time to plan the next feature iteration. A good iteration plan includes:
- Time frame: how much work, how many hours or sprints, when will we release the upgraded feature and when do we have the next decision milestone. Put a date on it.
- Numbers: What metrics are we trying to affect, what are our dream numbers. Be clear and be bold. Put down the numbers that will keep the feature alive.
- Changes, user stories: what are we actually changing and how, full description.
And now to the hard part: try to get everyone, all stakeholders, to agree with your plan.
I know it’s not always possible, but when it is, it’ll make your life easier. And what if we do all that and the feature, alas, still doesn’t do what is should? Then it might be good to remember the wise words of Stephen King from his book “On Writing”, part autobiographical, part advice to young writers: “Kill your darlings, kill your darlings, kill your darlings”.
Your product will benefit from it. Your users will benefit. You will benefit.
Tweet this: Know when to call it quits http://wp.me/pXBON-43s #prodmgmt #eol
About the Author
Liraz was born and raised on a Kibbutz in Israel,and currently lives in Berlin. Liraz is an experienced Mobile PM, writer and baker. She loves doing stuff that are used, or eaten, by others.