Three Ways to Scale a Collaborative Product Development Process

Three Ways to Scale a Collaborative Product Development Process

Everything you’ve worked toward is coming to fruition. The scope of work is signed and now it’s time for the real work to begin. While each product that your team develops is unique, not all work needs to be replicated.

Major VARs and larger consultancies are focused on solutions-based selling. They have an off-the-shelf product that is then tailored to generally fit the needs of the customer. Smaller, boutique shops offer the value of being able to develop fully customized solutions but they lack the infrastructure and resources to scale this approach well.

Creating efficient processes that can be industrialized across product teams is an effective way to scale the boutique approach and foster a collaborative product development process. Here are three ways we do that at Umbrage and that you can use to ensure your team is working toward as well.

Reduce Duplicative Efforts

Automation is great and is nothing to be afraid of. We’ve found processes that we can anticipate being deployed and build them out so they are rolled out at the beginning of a project instead of being part of the initial sprint. This standardizes our process so it can be easily replicated across other projects or multiple phases.

In an ideal world, when you create a process, you design it so it becomes standard operating procedure. I come from a Lean Six Sigma Black Belt perspective and strive to reduce duplicative efforts whenever possible. This includes ensuring proper documentation and capturing feedback in a way that a person who comes into the project blind can step in and perform a task if necessary. At Umbrage, we call this industrializing the MVP.

In order to reduce repetitive feedback cycles and loss of institutional information, we create a Home Base for each project. Productboard is a crucial component of the work we do, hosting our product backlog, roadmaps, and new feature requests. This central hub is the omniscient and omnipresent source of information, documentation, and statuses for a project. Home Base is especially helpful for products under continuous development. Many meeting recordings, notes, and decisions accumulate during that time and a central repository helps ground the team and keeps the project moving forward.

We also stress that we are striving for progress and not perfection. By having a repository of catalogued feedback, we can show how far a product has come and also have a way to reference past changes. When the stream of real-time feedback is available in the Home Base, not everything requires a meeting. Having the historical context is a powerful way for people to gain knowledge and help make continued forward progress. When you only see the latest version of a product, you forget where you've come from. Home Base enables the team to always be looking around corners. When we map out dependencies, the entire team is able to look forward, identify risks, and nobody is stuck waiting for a predecessor to get finished.

Get the Right People in the Room

Incorporating the human element to the beginning of a project is crucial for success. As we recently discussed, our intake process is more thorough than most solutions-oriented consultants. We aim to ensure we have a clear and mutual understanding of the problems we’re trying to solve together and a roadmap of where we are going.

The enthusiasm around a new product initiative can be contagious and you find yourself with a large group of stakeholders. One recent project had 35 people who wanted to be involved. We worked with the team to determine who are the actual decision makers? Who needs to be part of review check-ins and who are the representatives of the users?

When a large group of people are part of the stakeholder matrix, we can encounter the bystander effect, which can quickly cause significant delays. In order to avoid that, we introduce a RACI Chart. This establishes roles and responsibilities at the outset of a project and who owns assignments within the client’s organization. We empower our clients to own the RACI chart in a virtual whiteboard- dragging sticky notes of stakeholder names into each circle of the chart to determine the level of involvement in the product. And of course, Umbrage is alongside them the entire way to course correct if need be.

Umbrage also begins each of our collaborative product development projects by creating a team charter. We discuss how individuals prefer to give/receive feedback, how to win/lose their trust, and teach everyone how to document and access features in the Home Base.

While these initial human investments take time, they pay dividends. Oftentimes we pair with a client that focuses on the waterfall methodology and by introducing some of our agile framework, we are able to help them see the value in quick flexibility.

Agile vs. Waterfall and Ability to be Iterative

When people don’t want to change, you need to get their buy in and understand what’s in it for them. Many of us are stuck doing things because “that’s the way we’ve always done it.”

The waterfall methodology treats an initial deliverable as gospel and it is difficult to make changes and adapt to your users’ needs. If a new pain point is identified, the development team is often faced with a choice in the immediate. This leads to a sense of perpetual code freeze as stakeholders feel that if they don’t get a word in now, their opinions or feedback will never be considered.

The beauty of an agile methodology is that instead of a new feature displacing a current need, you can add things to the backlog and prioritize in real time. An agile team adds a level of care to a product ― they are able to pay attention to the details and make iterative changes. A constant loop of client feedback, implementation, and review pays dividends at the product release.

We were building a product for a large company with more than 30 stakeholders across four time zones. With 11 hours in time differences, we found giving the client access to designs on a virtual whiteboard helped them become familiar with the product and led to more productive conversations around design improvements with the limited time we could get together. We could then implement their feedback on the designs in an updated board and send it back out for review.

We continuously remind people that what we show you today is going to look different tomorrow based on the feedback we receive. When we show that iterating on a design or functionality is a lot cheaper than perpetually developing and releasing new versions, product development teams can easily see the value of the agile way.

When you bring the right team together with powerful tools such as Productboard, you can see how the boutique methodology of a collaborative product development process is scalable and leads to amazing results.