How to create a product vision that focuses on the customer
Delivering applications or systems that keep pace with evolving customer needs requires more than the adoption of agile KPIs in development processes. It requires a customer-focused, iterative mindset. By that we mean, any features that are included should be determined by how well they measure up to a product vision, not whether or not they were part of a pre-determined project plan.
This is not to say that plans are useless. It simply means that project plans should be guided by the product vision. The vision is what lights the fire in a software team and drives them to think about solving problems and not simply getting to the next stage of development. It also puts an emphasis on listening to user feedback in order to determine what areas will be critical to future cycles.
In this article, we will take a quick look at some of the best ways to create, communicate, and execute a product vision. Along the way, we’ll touch on things like the differences between a vision and a plan, hypothesis-driven development, and why user testing and metrics are so essential to a successful product.
Vision vs. plan
Over the last two decades, the agile approach to software development has largely displaced the traditional “waterfall” method. With waterfall development, no work began until a thoroughly documented project plan had been drafted and approved. Developers then followed this plan, step by step, until all the features had been built and the product was ready for release.
The big problem with waterfall development was that teams focused too much on meeting a deadline instead of delivering value. In most cases, customers wouldn’t see any of the features until the first release was completed. This wasn’t because the team didn’t want customer feedback, but because the drive was always to get to the next feature on the list instead of making sure each feature was done right. Consequently, it wasn’t until after a lot of time and money had been spent that everyone would discover some of the features specified in a project plan were unnecessary or, worse, a hindrance to user adoption.
Simply adopting agile processes, however, is no safeguard against these kinds of pitfalls. Even agile teams can lose sight of customer needs by letting resource capabilities dictate a plan or becoming too focused on making it to the next checkpoint. All efforts must be guided by a product vision that makes achieving value, not delivery of technical features, its sole objective.
Communicating the vision
In order for a product vision to bear fruit, the product owner must clearly articulate user needs in a way that both inspires and empowers the development team to take ownership of the solutions. This doesn’t mean describing the technical features a user might want but rather the outcomes they desire. The relative importance of each outcome also needs to be communicated, otherwise, the foundation of the product will suffer. Either the delivery team won’t harden the core product features or they’ll spend too much time on areas that aren’t critical to future cycles.
The best way to ensure a product vision is properly communicated is to keep it as simple as possible. The simpler the vision, the clearer the objectives will be. Take a hard look at every stated need and ask, “Is this really something most users will want, or is it an edge-use case?” Keeping it simple also gives developers more time to respond to user testing and build features that deliver measurable value.
Creating the vision for a product starts by writing stories that describe opportunities from the user perspective. What are the ways customers want to interact with you? What content or features matter most to them? What outcomes will save them time or improve their experience? Again, these stories don’t need to describe technical features a customer might want. All they need to do is define what outcomes would be most valuable.
Executing the vision
Once you’ve identified success criteria, it’s then important to execute on that success through hypothesis-driven development, which goes something like this.
- We believe <this feature or capability> will result in <this value>
- We will have confidence <this feature or capability> delivers value when testing yields <this measurable outcome>
This is why testing and metrics are so important. If any feature in a project plan fails to measure up to the KPIs dictated by the vision, developers should be empowered to eliminate it altogether. In this way, a team can leapfrog unnecessary parts of a plan and get to the features that deliver higher value faster.
The first release shouldn’t be over-engineered either. It should focus only on the most immediate customer needs. After the first release, developers can start introducing “teaser” features and track their acceptance rate. With this data, they can more accurately determine what features to build next and identify prospective Beta users. The team should also use each release as an opportunity to harden those features that are seeing the most use.
What’s your vision? We can help.
Defining a product vision can seem daunting, particularly when you’re struggling to manage multiple products and keep stakeholders happy. Having an outside resource who understands these struggles and can offer some insight might help.
Whether you need to bolster your IT staff to scale production, accelerate and evolve IT practices, or optimize your business processes with technology, we have a delivery model that’s matches your goals. To help you get started, we created an interactive tool that matches you with the engagement model that’s best for you. You can check it out here.
Looking for a deeper dive? Get in touch with one of our solutions experts for a free 15-minute consultation.