5 key design decisions to consider in your product process

This article was co-written by Kate Villanueva, Denae Foster, Boge Sotirovski and Haley Miller, members of Productboard’s Professional Services team.

There are a number of reasons why you might want to revamp your product processes. You may be trying to improve efficiency, account for new people, or bring your company into the next stage of maturity. Whatever your reason, it helps to take a systematic approach to your design decisions. As members of Productboard’s Professional Services team, we’ve been lucky to take countless teams through the process of defining their future state and taking steps in that direction.

Before we dig into the questions that can guide your transformation, let’s establish a few ground rules:

• Involve a select group of stakeholders to align on the key decisions together
• Be critical before finalizing your decisions—assess the pros and cons and impact to people and process
• Document the key design decisions to build transparency and traceability

When we work with product teams to optimize their product processes, we work through the following five key design decisions together.

Key Design Decision #1: What does each stage of your product development process look like?

From discovery to release, defining each stage of your product development process allows your team to understand what actions and activities need to take place at each stage. 

When you set up the stages, consider implementing some standards and rituals that will set product managers up for success when moving a feature through the process. 

Assigning a status for each of your product development processes makes life much easier when tracking the progress of a feature throughout its lifecycle. Here are some common stages you can consider:

1. New Idea
2. Candidate
3. Planned
4. In Progress
5. Released 

After you create the stages, imagine if you defined a set of actions and criteria that needed to be met during each one. Some standardization across your product organization will make for a smooth product development process and improve your chances of success when rolling out products that matter.  

Key Design Decision #2: Who are the audiences for your product roadmap and what information do they need to see?

There’s a good chance everyone in your organization is interested in roadmaps. The tricky part is that each group of stakeholders has their own specific needs and priorities—there’s no one-size-fits-all roadmap that will work for everyone.

How do you possibly understand everyone’s needs and create something informative for everyone? The simple answer is—you create and cater your version of the roadmap to your audience. 

Some common teams to consider when roadmapping are: sales, marketing, customer success, leadership, investors, and, of course, your product team. What’s relevant to each audience and what outcomes are they looking to achieve after consuming the roadmap?

Here are a few examples of how you can create a roadmap that is customized to the needs of different stakeholders. 

• Use leadership roadmaps to give senior executives and stakeholders a 1000-foot view of the product team’s work. These high-level roadmaps provide quick summaries of your product direction. They can include information such as the market opportunity and profit and loss details with the ability to dive in deeper if needed.
• Use company roadmaps to share more details with cross-functional teams like sales and customer success. These roadmaps allow other teams to set appropriate expectations with prospects and customers and contribute comments and relevant customer feedback.
• Use delivery-focused roadmaps with granular timelines for development teams that want to know the details. Communicate objectives, status/stage of development, areas of your product, and account for other work they need to support. Leverage dependencies and capture risks.
• Use customer-focused roadmaps to zero in on features customers care about most. These roadmaps also communicate what’s coming up next for your product to internal customer-facing audiences such as sales, customer success, and marketing. 

As you can see, collaboration is key when building out roadmaps. Roadmaps should reflect the outcomes the organization is trying to achieve and equip you with information to answer the common questions of: “What are we doing next?”, “What’s the actual plan?” and “Why are we doing this now?”

Collaboration amongst stakeholders and cross-functional teams is going to rally your organization around the vision, keeping everyone informed and involved! 

Key Design Decision #3: What types of requests or feedback should funnel to the product team and who should be providing them?

Capturing the opinions and experiences of your customers—whether positive or negative—will enable you to adjust your actions, validate your ideas, and ultimately deliver better products. This data can be used to prioritize user needs, which in turn complements the delivery cycle and transforms validated product ideas into valuable product functionality. 

It might sound straightforward, but keep in mind that product feedback can come from various stakeholders and not just the end-users of your product. This might include:

• Stakeholders in your organization who regularly engage with your end customers and prospects and hold a lot of knowledge (think go-to-market teams like customer success, sales, marketing, etc.)
• The design teams that record discovery notes and engage in usability testing
• The support teams that share requests and feedback from support tickets and channels
• Executives who shape the product vision and priorities

You can see how this results in product feedback being all over the place, making it hard to keep track of and even harder to know what truly matters. By opening up dedicated channels and answering questions such as “What is the ideal feedback to share?” and “How do you submit good feedback?” you can set up a better and more efficient way to collect and process the feedback. Try to open as many feedback channels as possible and make sure you address some of the following:

• What are you trying to do?
• What problem are you trying to solve?
• How are you doing that now?
• Can you give me an example? 

Ideally, all feedback should be consolidated in one place to serve as the source of truth. 

Why is all of this important? For product teams, it is the increased efficiency and ability to allocate time to high value tasks, as well as knowing why the things you’re building are important. For leadership, it drives a happier, healthier, and more productive environment for the teams. And for the go-to-market teams, it allows for the possibility to seamlessly share feedback and get a central view into the top needs and requests from customers, prospects, or partners. 

Key Design Decision #4: What should your product teams consider when making prioritization decisions? 

Making prioritization decisions is one of the hardest tasks for a PM to do. If there’s no guidance on how to approach this, it opens up potential challenges like: lack of data-driven decision-making, letting the loudest voice dictate, or prioritizing without the overall strategy in mind. 

While there are a number of different methodologies out there to help you prioritize (RICE, Value vs Complexity, KANO, etc.), deciding on what to build next typically boils down to answering few questions:

• What do users need most?
• What best supports your product strategy?
• What will help you sustain and grow your business?

If you are just starting out, it’s important to remember that whatever methodology/framework you choose, you should still consider several prioritization factors:

• Who do you need inputs from?
• Who needs to own the decision-making?
• How will you share the prioritization decisions with others?

If you are to make the most of your valuable time and resources, you simply cannot do everything that is requested from you. You need to make sure you prioritize strategically and base your decisions with context–this is where a standardized prioritization process comes in. Make sure to frame your process around clear objectives, product strategy, actionable metrics, and targets to achieve. 

Key Design Decision #5: How should your product teams close the feedback loop with their stakeholders?

So, what are product feedback loops? 

Here at Productboard we think about a product feedback loop as the process of collecting customer feedback continuously and improving your product based on these insights. Ultimately, well-defined feedback loops help you to store valuable information, make necessary changes, and build a product that customers will truly use and love.

When your customers provide you with thoughtful feedback (whether through a customer interview, survey, sales discovery call, support ticket, or social media post) it’s important to close the feedback loop to show that their inputs are valuable. By embedding this in the product process, it helps build relationships with customers and further encourages them to engage with you in the future. 

Think about the process on how your product teams can close the loop. Perhaps the team can follow up with customers that specifically requested the feature, conduct additional interviews/surveys to elicit feedback, invite customers to a private beta of the feature, or release communications to celebrate feature launches. Closing the feedback loop will not only keep customers informed (and hopefully, excited), but as a PM, you will also be able to validate whether the feature solves the problem and capture additional feedback to iterate on. 

Now you have a quick overview of each key design decision and some of its main components. But you could easily dive more deeply into each topic, especially if you know it’s a specific area of concern or interest within your company. If you’re interested in learning more about how we’ve helped our customers work through these decisions, reach out to our services team. You can also watch the on-demand webinar “Change Management 101: Building a Scalable Framework,” to learn how to build a strong change management framework.