Which Features to build?
The hardest ongoing challenge product teams face is to figure out which features actually should get built & why …
I love coming up with new ideas. I love prototyping features. I love strategizing about where to take a product. I love to brainstorm with fellow product people. There are few things that are as exciting as coming up with clever & elegant solutions to problems & use cases you care about.
It’s one of the things I love doing the most.
It’s complex, fun and incredibly satisfying.
While coming up with great features is an important part of product management for me calling the shots on which features go in and which features stay out is where the real magic happens.
Coming up with ideas is easy compared to editing them down.
The better you are at coming up with fascinating ideas the harder it gets to say no and to get back to clarity and simplicity. It is a constant struggle.
Editing is the real challenge. Andrew Chen wrote a brilliant post on why it makes sense to think of product managers as product editors inspired by Jack Dorsey’s thinking.
Usually you will have hundreds of ideas on what would be a great addition to your existing product. Yet the main problem is that you are strapped for resources. Focus, time, money, you name it.
So how do we pick what really matters?
I recently started to use a check list of attributes I think about before we actually decide to start work on a certain feature. Here we go …
- Positioning (Clarity)
Does it help us with positioning in the market? Does it add clarity to our product? Will it help people to better understand what we stand for?
— See Minimum Viable Personality via Fred Wilson - Super powers (Value)
Does it add super powers to our customers? Is it something that delights them? Something they care about?
— See Kathy Sierra’s talk from Business of Software - Used often (Frequency)
Is it a feature that people will use often (whether actively or passively). How often does it create value to them? Is it something that helps them over and over again?
— See Des Traynor’s post on prioritizing features - Low Effort (Lead Time)
How fast can we deliver this? How much implementation risk do we have? Have we done something like this before or do we know someone who did?
— See Des Traynor’s post on Features & Physics envy - Easy to grasp (Lifecycle/Immediacy)
Do our customers get it immediately? Can they use it instantly? Or do they need to become experts first? Can it create an epiphany in the onboarding phase or even sooner?
— See Hiten Shah’s insight on front-loading a-ha moments - Tweetable (Word of Mouth)
Would someone tweet about it? What? Why? Is it a 10x improvement?
Is the execution so great that your customers think “Why didn’t everyone do it like this, this is how it should be”?
Is it just “good enough” or is it worth to share it with the world?
— See “building for tweets” via Wayne Chang of Crashlytics via Jason Evanish
How do you decide about what gets built next and why?
Any tips and tricks you’d love to share?
