Probably the hardest job the executive team has at SEOmoz (beyond improving culture) is managing the prioritization roadmap for features. Right now, the vast majority of the Moz engineering and product teams are working on a large release that will likely be 12+ months from start to finish (which is actually something we hate – we’d all far prefer to do agile, iterative development – more on that decision once it’s done, which will be a while). But several of our teams, including the folks at Followerwonk, are sitting down to plan out the next few months of feature additions & refinement (as I noted earlier on Twitter, there’s actually a survey related to Wonk’s future development here).
(via davecito on Flickr)
I wish that the process was straightforward and simple. In an ideal world, we’d connect with a few users in person, talk to our customer advisory board, put up a survey, and come back with data that formed a clear consensus. Yet, in the history of the company, I can’t ever remember that happening. Feature discussions, particularly in survey data from users, usually look like a US presidential election: 49.9% to 50.1%. Not exactly a ringing mandate.
This, among other reasons, is why, when we engage in product planning, we’ve learned to prioritize features and engineering investments based on the results we care about most. Those could be any combination of:
- Attracting more customers with profiles similar to our existing customers
- Attracting customers in a new segment that we don’t currently reach
- Keeping existing customers happy and hopefully extending the length of their subscription
- Signaling entry into a new area (e.g. last fall when we launched the early version of social analytics)
- Making a wild guess and hoping it resonates with new or existing customers, but basing it on intuition more than data
With any product/engineering process, you want to prioritize the goals first, the who second, and the data input third.
That sounds crazy! Who takes the time to ask their customers/audience what they want and then potentially ignore or minimize those contributions when deciding what to actually build? Clearly, only companies that hate making money.
Well, like I said above, it’s not that simple. Building what your existing audience wants may limit your growth potential, particularly if you’re building very niche products for a niche audience. It may also kill innovation before it’s had a chance to flourish or impede the development of ideas that your current audience has a hard time imagining, but would love if they existed. You also may find that the customer requests don’t work well with your business model. For example, if you’re running a subscription based service, focusing on one-time-use products over consistently needed and valuable features may be fulfilling your audience’s requests, but it’s going to seriously harm your ability to stay in business.
This is why you have to prioritize based first on the company goals, second on the audience you’re attempting to delight, and finally on the feedback you’ve received from the market. It may violate some of the principles espoused by startup philosophers like Eric Ries and Steve Blank, but I think that’s OK. Challenging conventional wisdom has often proved fruitful for us 🙂
p.s. Obviously, this post is sharing only a very tiny fraction of how the Moz team does product planning and prioritization, and I’m sure we’re not yet experts at it. In the future, I hope to share more, perhaps with input from Adam and other folks on planning, about more of the nitty gritty.