A Broader Approach to Product Roadmap Input

Let’s be clear: we’re all for feature requests. They’re definitely imperative. Managing feature requests and prioritizing new features based on client feedback and other market research and insight is key, key, key to evolving products that people need and want to use. We love the lean startup way so learning and iterating based on input is right up our alley…

But…  (You knew there was a but, right?!) But, when feature requests are the only thing that you’re thinking about and considering when you look forward and build out your product roadmap, well, that’s where we say, hang on a sec, there’s more to this…

Product Management as One (Integrated!) Pillar of Growth

There’s more to Product Management than roadmaps based on feature requests. Why?  Product is one of the key growth areas for startups and scaleups, so it’s key for Product to be aligned with the other key growth areas: Sales, Marketing and People.  Really what we’re saying here is that growth is most likely when your whole team and company is aligned around the same vision of growth. So before thinking about specific feature requests (even if they are relayed urgently from your top customer, and, yes, we get it!), think about the overall moonshot of what you’re trying to achieve and ensure that everyone has an understanding of and buys in to the big picture. Planning with the moonshot in mind is paramount to moving toward your overall “why.”  (And we’d be remiss to not mention that, of course, Product is ultimately all about solving a need for your ideal customers – a real need that resolves real pain and that they’re willing to pay for…)

The Feature Request Game

Whether you’re early days with a few early (maybe even pilot) customers, just gearing up with a few early adopter clients, or really rocketing up into the scale-up stage, if you have people using your product or solution, you’re going to hear about their ideas for how to make it better.  Like we said, that’s a good thing.  It’s just that sometimes it’s the only thing.  And so what if it is?

FOMO: The trouble is, if you’re only evolving your product forward based on specific feature requests from certain clients or users, then you may be missing out on considering features or product ideas that might come to light by exploring other sources.

Bias (your roadmap): Plus, you could be inadvertently biasing product development to the current clients (the largest revenue clients or the clients that provide the most input) at the cost of building a product that other clients, prospects or markets might desire, and which could be integral to the future of your company.

Last, you risk having a short-term focus and be constantly “chasing user happiness”. By the time you build that feature one user has requested, they’ve moved on to a new shiny feature request. And you risk missing the potential for big leaps in functionality or surfing the wave of market trends when you are responding to feature requests only from existing users.

Moving Beyond: There’s More Out There

Ok, if you want to consider moving beyond feature requests, what are some additional things to think about?  Here’s a few:

  • Focus on the problem, not the feature. The feature is the proposed solution. Plenty of creativity remains untapped when you fall in love with the problem, and then identify different approaches to best solving it.
  • Are you playing catch up or leapfrog? Many feature requests (especially from sales) are designed to help your product catch up with competitive solutions. Instead, be sure to consider how you can leapfrog competitors.
  • Don’t forget technical debt. As a product evolves, sometimes we need to take a few shortcuts here and there to meet a date. Over time, this accrues as technical debt. If not addressed, it hampers our product scalability, quality and speed. So don’t chase new features at the expense of addressing your technical debt – it’s a balancing act.
  • Be clear on the “who” – who wants, needs or benefits from a feature. Many feature requests are targeted at power users – those who are already raving fans, active users, who will take the time to submit a feature request. But sometimes there are real gains to be had when we seek to address the challenges of new users, those recently onboarded who haven’t yet seen the value. Or buyers – what features can you add to remove sales friction, and drive better sales outcomes. Or your internal users – your services team, what tools could make them dramatically more productive.
  • Use a different lens: get client/user feedback on your moonshot. Feedback is information.  Definitely ask clients and users for feedback on the current product/solution and their ideas about how to move what’s now to what’s next in terms of features and experience.  And then embrace the power of “and” to also ask them not just about features, but also about your moonshot.  Articulate to your clients and users the dent you hope to make in the universe and seek their ideas about getting there.  You may turn up fresh insights that can inform your product development.
  • Blue sky thinking: keep on keeping on with the market trends and opportunities assessment. We don’t want to go back to the days of Henry Ford (who allegedly said that “If I asked people what they wanted they would have said a faster horse; fun note: allegedly as this HBR article notes that there’s little (no) evidence that he actually said this) as we’re all about moving forward, but the point is that, in addition to input from current and prospective client, you can also add in your own input on trends, happenings in related spaces, emerging technologies, nascent business models and the like.  All of these collectively are the market trends and opportunities and thinking about them outside, without being fettered or strictly focused on feature requests, might lead you to some new ideas about how to evolve your existing product – or how to add on an ancillary product that your base needs and wants.
  • Back to the buyer: map out the ‘disruptable’ elements. What are your clients and prospects trying to do? What pain are they trying to solve? How do they do it now? Where are the friction points? What most frustrates them?  Where are the opportunities to move beyond “that’s the way we’ve always done it” to a constructively disruptive future new way that benefits them more? Asking these questions and mapping out the now can lead you to insights about building a better future.

So when it comes to feature requests, we say yes – yes to continuing to use feature requests to inform your product roadmap.  And then we say, more is more, meaning that input and assessment from different sources and asking yourself and your client to see the future through different lenses can lead to a more fulsome, future friendly evolution of your product.  Here’s to broader product roadmaps and product management for growth!

This post originally appeared on Alberta Enterprise Corporation’s Start Alberta portal.