How we’re solving the Product Triad collaboration problem
If the title triggers some skepticism, that’s a good thing. It’s not an easy problem to solve. Here’s what’s working for us at Later.
Explaining the problem
Triad collaboration is a challenge for software companies that likely results in untold lost revenue, inefficiencies, sub-par products, personal stress, anxiety and countless slack messages.
What’s the product triad collaboration problem? It’s a problem (and opportunity 🤓) that arises because Product Management, Engineering and Design (a.k.a. the Product Triad) each contribute their unique perspective in order to create an optimal product. They need to make decisions together.
But experience has proved that this is more difficult than it sounds. Each part of the triad has its own interests, processes, language and points of view. It’s like three different cultures coming together to get something done.
Here I’ll share what we are doing a Later. It’s just one approach, but I think that it is moving us in the right direction.
I’ll give away my thesis here.
I think the best chance we have to solve this problem is if every part of the triad goes out of their way to understand the processes and language of the other parts.
Our story at Later starts with our Product Management leads, who began advocating for an approach to product development that was popularized by the PM team at Basecamp in their article titled Shape Up.
They had first shared it with the PM team as a way to improve the overall product development process including the Product Spec.
The PMs were onboard from the start. It’s a great process and promises many benefits in terms of product development efficiency.
The article had also been shared with the design team, but it fell flat. The designers saw it as a PM process that gives too much influence to PMs over design outcomes.
I think the designers reaction to the the Shape Up process illustrates one of the challenges of triad collaboration. We can feel territorial about what we contribute to product development.
The main issue that I could see with the Basecamp article from a design perspective is that it is written by PMs for PMs.
For example, in the section “who shapes” which describes who should be involved in providing shape to the early product ideas, makes it sound like it’s primarily a PM task.
“Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard or with a close collaborator.” ~Shape Up
This can sound scary to designers who already sometimes feel like they don’t have enough agency in the overall product development process. Would the PM actually include them in the sketching exercise?
This leads us back to the main point in this article.
The issue is often not the process itself. The process in Shape Up is a really great process. But process alone can not solve a human problem.
From a design perspective, it is in our best interest to build a trusting collaborative relationship with our Product Managers. We both want the same thing, which is to create a great product for our customers.
Design needs to influence the direction of product. Not because of ego primarily. Of course there is some ego. We’re human. But we as designers care a lot about what gets built. We want it to serve our users.
When we don’t have enough influence over what we build, we tend to get disillusioned and unmotivated, and disengaged. This can lead to designers going into passive mode where they just wait to be told what to design. This is not a good state to be in. Instead we want an engaged and energized design team who is excited about contributing.
For this reason, it’s also in the PMs best interest to collaborate with their designers. The same is true for engineers.
While I can’t speak for engineers, based on conversations I’ve had with devs, I believe that they feel the same way as designers in terms of having a vested interest in what we build. They also can get demoralized if they don’t get to bring their perspective and creativity into the process.
Plus if technical feasibility is an after thought, UX designers and PMs have to work around technical limitations on-the-fly resulting in bandaid-type solutions. But bringing engineers into the discovery phase allows us to be proactive about technical limitations and build a more robust experience from the beginning.
This leads us to another important point in this article.
We should all take the perspective that it’s in our own best interest to go out of our way to collaborate with our product triad partners.
If we have the attidude that our partners should do the work of understanding our perspective, we will likely fail. In fact, this will kill almost any relationship. There’s a life lesson in here somewhere.
And so for us as designers this means that we should go out of our way (i.e. try really hard) to understand the motivations, concerns and strange lingo 😅 of PMs and Developers.
Here’s what we are trying at Later
There were two main problems we wanted to solve at Later.
- How do we get the best ideas into the prioritization framework so they have a chance of getting built?
- And and how can we improve the accuracy of our dev estimations early in the process so we don’t don’t get into the situation where we can’t build something we had already committed because of the effort required?
And a third problem. How can we do this in a way that each part of the triad feels like they have had a chance to contribute to the outcome?
So for us at Later, we approached process design as an experiment. We had an idea to make a collaborative process based on the Shape Up model. PMs, Devs and Designers worked closely together to figure out something that can work for us.
I’d say the simple fact that we collaborated together on the process is one of the largest factors in the success of the process.
We prototyped the process by having one of the product squads test it out.
And this is an example of how great it is to work in a company where the PMs want to collaborate. Mark Jones, one of our GPMs approached me one day and said let's meet up and talk about how we can have a more collabortive process between PMs and UX design. This was the beginning or our process experiement.
We chose a product squad to test it out that already seemed to be collaborating well, mostly because they were already super open to figuring out how to collaborate even better. Amy Scott, one of our PMs and Jess del Rosario, a UX designer on my team, agree to be our test subjects. Without this willingness to try out new things, we wouldn’t have been able to move forward.
We tried out the shaping exercise experiment we had in mind. Amy and Jess refined it into something that could be used by other product sqauds. And then for this previous cycle we rolled it out to all teams.
And overall this new process has been working great for us.
Now all of us, Dev and Design included, have adopted what was originally a PM’s process, the Shape Up process. Together we have morphed it into something that represents all of our interests.
Here are some key parts of the process we came up with…
Part 1 of our solution: The idea rationale template
At Later we have a well defined planning cyle. Which starts with an unvalidated product idea. This product idea must be formulated in a specific way before it can enter the funnel of ideas. For this the PMs have developed what we call a ‘Rationale Template’.
Now, no designer would ever naturally pitch an idea using this template. It’s not written in our language. We would have a customer problem justification for a design idea, but we don’t normally think in terms of strategic fit or business quantification.
But getting back to this idea of understanding the language of our triad partners, if we as designers want to have a product idea taken seriously by our PM counterparts, we realized that we need to put our ideas into a language they can understand.
Using this template, anyone can submit an idea whether they are a Dev, Designer or PM. It’s a good starting point to get everyone on the same page about the value of an early idea.
Part 2 of our solution: The shaping exercise
We have modified Basecamp’s ‘Shaping’ exercise to be more collaborative. Each sketching session includes 3 people, one representative from each of the Triad teams (PM, Dev, Design).
Once an idea has been submitted using the rationale template, it’s eligible to be scheduled for a 1.5 hour sketching session. See below for a sample agenda.
The sketching sessions are meant to produce low fidelity drawings of the product idea. The purpose of the drawings is to communicate the idea sufficiently to narrow scope and to enable dev estimation. The drawings should not look like visual designs or even wireframes. It should be clear that they are just concepts at this stage.
The drawings should look something like the following. We use Figjam. And it’s okay to use screenshots of the existing product.
These drawings then become a foundational element in the creation of the Product Spec, which is then placed in the prioritization framework we use for cycle planning.
Once again, a big thanks to Amy and Jess for figuring out an effective way to run these sessions.
Learnings and ongoing improvement
We’ve tried our Shaping process for one full development cycle now, which for us lasts for one quarter. Overall the results have been great. We’ve had positive feedback from all parts of the triad.
What’s working
- Having a time box of 1.5 hours for sketching is good for productivity
- The devs appreciate getting involved earlier so they have a better understanding of the proposed designs
- Keeping the shaping sessions small (3–4 people max)
- Circulating a doc with context and rationale before the session
- We are getting better ideas by having early collaboration
- We are able to reduce the scope of ideas earlier
What’s not working (yet)
- We don’t always know which ideas should go into a shaping process
- People doing the sketching don’t always have enough context to contribute meaningfully
- Sometimes we need the perspective of both front and and back end dev, but our shaping session only allows for 3 people to be present
- At Later our design discipline is segmented into UX and UI design, and we want the perspectives of both UX and UI design, but once again, the sketching session works best with just 3 people
- The practical task of setting up the shaping session with enough lead time has not yet become routine for us
So a key issue we’re still having is not getting all the inputs we need into the sketching sessions (this includes user research and the perspectives of other key stakeholders).
We can’t add everyone into the shaping sessions. It would make those sessions too costly and inefficient. But are there ways that we can get valuable inputs from these stakeholder groups into the process? Something we’re still working on.
Those are my thoughts and reflections to date (19 Sept 2022). I’ll add more here in the future when we’ve iterated on the process a few more times.
How is your team solving the Triad Collaboration Problem?
