Our client partners see their web sites/applications as something to improve often. They want to try new things on their sites to better engage and inspire their audiences.
One of the challenges for many organizations is figuring out what changes to focus on next. Often there are many competing voices expressing what is lacking from a website. A program team wants to fix some usability issues. The fundraising team has ideas to better engage supporters. It is hard to create an opportunity to hear from all stakeholders. It is even harder still to decide which voices to listen to in particular with limited budgets.
How do you decide what to do next with your website or web application?
The following 3 steps should help get you started.
I'm going to share a method that I was part of in my pre-MOD-Lab days. For over six years I worked as part of an educational technology startup. We created a web application to help teachers integrate technology in the classroom. I wore many hats during those years. I helped to build a help desk, deliver in-person training, to support sales, and serve as a technical project/product manager.
I also was part of a group that convened to talk about our web-based tools and how they should evolve. The team consisted of people, each representing different perspectives of the business.
This group, the “Product Team”, includes representatives that advocate for different audiences. Each member brings a diverse perspective that breaks down silos. As a team they share a challenge to work, sometimes very hard, to come to consensus.
Creating a team is an important first step. When doing so, consider what each team member’s area of focus is. Which audience type and/or organizational perspective will each represent.
For example, a nonprofit’s Product Team might include the following members.
Your Product Team is an opportunity to put your target audience's voice and needs first. When you bring people together from different areas of the organization you'll increase the potential of your website.
A roadmap outlines future work on a timeline. It is a working document that helps to establish a sequence of priorities. Often a Product or Digital Lead is the “owner” of the roadmap. But the document also serves all members of a Product Team. The roadmap showcases the shared vision of the team and the future of a website.
How and where you create a roadmap is flexible. Below are some links for further reading. They address topics such as the different styles of roadmaps you might use as well as some popular tools to manage them. It is important to find a style and to use a tool that you believe works best for your organization.
When working with roadmaps we recommend including the beneficiary and the need that is being addressed for each item in it. How is something you want to add or change on the website addressing a particular audience’s needs? Putting people first humanizes your roadmap items to be more than a list of features.
Your roadmap should be a sequence of problems you want to solve, not features.
-Paige Costello - Pillar Lead, Core Product at Asana - https://youtu.be/mt8PCPqKyrI?t=210
Back at my educational technology company each team member prepared for the meeting.
At the start of the meeting, each person shared their update. Then the Product Lead led a review of the current roadmap. Finally, there was a lively discussion about additions and/or revisions to the roadmap.
The meeting made sure to provide an opportunity for each stakeholder to present. Each had a voice to share updates, needs, and issues.
The challenge of these meetings is that folks are not going to agree. Sales/Marketing is more often concerned about the features that don’t exist yet to help drive sales. Support often is advocating for making what the product does now do it better. A method for working through competing priorities is important. There are many models to choose from.
In a benevolent leader approach, each team member presents their updates and recommendations. A designated leader, often a business lead (CEO), then makes decisions on priorities based on the information shared.
A more democratic approach is to use a point method. Each Product Team member gets a budget of points and applies them to features/changes. A common rule is that a team member can’t apply her/his whole budget to one feature. This forces members to consider the needs of others. So for example, you might have a budget of 7 points and the most you could spend on a feature/change is three points. At the end of the meeting scores tallied and values used to help establish changes in the roadmap.
In my experience, there is value in stakeholder opinions and having visionary leadership to help drive the direction of a website. But these are two models to consider for your organization. Below is a link to further reading about many more.
The technology company experience I share here did not start with a defined process. The leadership convened a multi-disciplinary team together. We discussed the direction of our web application. We recorded our roadmap in a Microsoft Word document. It was not a very structured effort, but it was a very productive one.
It is my hope that you find this encouraging. You don't need a well-defined process to build a Product Team and discuss the future of your website. In time you can add a process. The team can work to improve and codify how they operate.