Moving Beyond MVP: Feedback, Features and PricingAdded to Business
Building a minimum viable product (MVP) can help businesses get a working platform to market quickly. It helps validate product hypotheses and attract new users to your service. But how do you expand your product beyond MVP? How do you price your platform appropriately when you aren’t sure of the right mix of features and value for users?
We consistently tackle this challenge for our clients, and for our own internal products. Recently, we partnered with Mike Cohn of Mountain Goat Software to redevelop PlanningPoker.com, an agile estimation tool used by software development teams around the world. We developed the core technology and design during our 2014 Race to 3:52 Hackathon, and in the last few months we’ve moved from beta testing to full launch.
Here’s the process we used for Planning Poker, which mirrors our approach to most digital product builds:
Listen to Your Users
Gathering user feedback and data is nothing new, but many product teams limit their feedback loop to user experience concerns like interface design. While usability testing is invaluable, prospective users are also a rich source for product feature ideation and refinement. One of my biggest missteps as an entrepreneur came from failing to launch quickly and get feedback from real users.
For Planning Poker, we knew it would be important to gather user feedback early and often. Fortunately, we had the luxury of an existing user base of passionate professionals, but we needed to provide them the tools to voice their opinions.
The beta version included a prominent callout for bug reports, feature requests and general feedback. This built-in feedback tool dramatically improved our Quality Assurance cycles, quickly identified bugs and left us with a backlog of more than 100 potential features for future iteration.
There is simply no substitute for a strong user feedback cycle when it comes to feature ideation and prioritization. It will help you validate your product roadmap, as well as your UX design decisions. Constant feedback can help you determine which path to take at the start, but you should also have a long-term destination in mind.
Set a Long-Term Vision
To be successful, digital product teams need a strong vision for their product and a clear understanding of how their platform meets a market need. Who are we building this for, and what problem are we solving? Those questions can help you determine your immediate future, but more importantly, they become the lens through which you’ll see your long-term goals.
What do we want this product to become?
We held a Sprint 0 for our team to answer those questions and set a clear path for the next 18 months of Planning Poker.
We were sure that Planning Poker could be much more than just a useful estimation tool. To set our vision, the entire team sat in a room and identified the product’s key advantages, then we wrote a full value proposition. We reviewed user feedback, talked about taglines and envisioned newspaper headlines we’d like to see if a journalist wrote about our product 6 months after launch.
Through these discussions, we realized we wanted Planning Poker to be more than an agile development estimation tool; we wanted it to be a holistic sprint planning tool.
Divergent product visions will emerge through these discussions, and that’s OK. Some members of our team believe strongly our platform can solve planning issues for many groups beyond software development, and that’s fine. Long-term strategy should not be confused with long-term vision, and divergent strategic paths can be explored throughout the product lifecycle.
Ultimately, we knew that we only had 6 weeks of development to add new features and functionality to move us further toward our goal, so we had to strike a balance between effort and user value.
Estimate, Estimate, Estimate.
Your most important early features will come from the sweet spot between compelling impact for users and engineering effort from your development team. With a huge backlog of feature requests and ideas, we did a lot of sifting to find gold.
We pulled in a few hundred user suggestions, and the team employed t-shirt size estimation for the effort required for each task: XS to XL. This allowed us to rapidly assess low-complexity tasks and gain broad consensus on the relative effort of each task. As we progressed through our feature backlog, we prioritized high-value, low-complexity issues.
Build Features for Buyer Personas
Of course, determining high-value features requires knowing our users. Given our focus on user feedback and testing, we had a wealth of knowledge to help us build buyer personas for a full set of potential customers.
We know that enterprise-level clients need data security, so building a highly secure version of the tool is a necessity – a high-complexity task, but also very high value. A scrum master at a small agency, on the other hand, may value ease-of-use over anything else, so remote access and robust import/export tools are key.
Once you identify your core buyer personas, orient an ideal feature set to each persona. Once you have features in mind for a user group, it’s time to think pricing.
Align Pricing and Personas
What is the most important use of our platform for a customer, and how much are they willing to pay?
These are the core concerns for any pricing strategy, and the easiest way to answer them is to align product offerings with persona needs. Once we identified our top features through user feedback and estimation, we spent the afternoon pairing features with our buyer personas.
We then created “buckets” for each of our pre-determined pricing levels (Corporate User, Power User, Small Team, etc.), and made sure each of those buckets aligned with one of our buyer personas. This alignment allowed us to go back to our features and simply drop them in the corresponding bucket.
We set our initial pricing levels based on the pricing of similar SaaS products with similar buyer personas, but we won’t know if we got pricing right until we see if customer start signing up. We may A/B test different pricing pages and plans, and we will be ready to refine pricing as we go to optimize conversions and ROI.
Prepare for Change
Setting features can be daunting, and it’s important to remember no team or product owner has all the answers. Your product roadmap should help you keep a destination in mind, but it’s critical you remain flexible enough to respond to the needs of your users with each new iteration and launch.
Geoff Wilson is President and Founder of 352 Inc., the digital product development agency he started 17 years ago out of a fraternity house room at the University of Florida. 352’s 85-person team creates complex websites, software and marketing campaigns for clients ranging from start-ups and mid-size businesses to prominent brands like Microsoft and Wells Fargo. 352 has offices in Atlanta, Tampa and Gainesville, Florida.
352’s product development teams combine expertise in user experience, design, Web development and digital marketing to create websites, apps and digital experiences that drive engagement and business. Leveraging agile and lean methodologies, 352 builds online products ready to launch in weeks, not the months required by typical digital agencies.
About the Author
This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.