Case Study: Product Leadership for B2B Teams

TL;DR:

I created a product-inspired process to help B2B teams at Betterment collaborate smoothly. My job was to encourage communication and good product strategy in a marketing-heavy role.

The Problem

I was the lead (and only!) designer for both of Betterment’s B2B marketing teams simultaneously. I had two stakeholders competing for my bandwidth, and no defined owner to make prioritization decisions.

On one hand, we had multiple people on each team providing input, and not much consensus on what the final product should be. And on the other hand, it was hard to pin down which of those people was responsible for what things, and by when.

The User

In this case, the ‘user’ was a little unconventional: it was the members of my two teams. It was myself as the designer (and often engineer), the marketing director and marketing managers, the heads of both business lines, and the business development and salespeople that depended on the work we were doing. Sometimes your internal team ends up being the user you need to solve problems for.

Research

The research in this case was a few months of struggling to complete work in an efficient and fair way. We had one business line that was hot on the press front, so there was a lot of work to help make onboarding new clients more efficient and reduce manual work. And we had another business line that brought in a significant amount of assets, and needed a lot of help on the acquisition front to get the word out. We didn’t have an agreed-upon way to decide which of these business goals won out, so I tried to please everybody.

Once I realized that working my ass off was not sustainable, I started speaking to people on both teams to find out what was working and what wasn’t. I looked into what kind of projects would be most important given the roadmaps of the two products. I also looked at what was working on the other marketing and product teams, as they were prioritizing many projects successfully.

An interesting thing I realized during the research is that one of the pain points is that we have many sizes of projects. Large website builds need more planning and strategy work than a simple piece of print media. So whatever process we decided on going forward, it would need to accommodate both kinds of projects.

Exploration

I chose to think about this problem from the perspective of a product agency, and started planning out a set of process, roles, and responsibilities. Any solution I created needed to give clear accountability and communication expectations to both teams.

I decided that a sensible first step of the process would be a kickoff. It made sense for the product owner to be responsible for scheduling the kickoff, as well as coming prepared with a well defined problem to solve, an idea of scope and resources required, and any timing factors.

The major point of the kickoff was to get everyone involved in the same room for discussion and to agree on the problem we’re trying to solve. It’s amazing how many misunderstandings you can avoid when everyone is talking to each other in real time. The secondary point of the kickoff was to establish a well-defined problem to solve, not an end result of something to build. Once we talked through all of this, we would all agree on the requirements based on the problem.

The kickoff also helped address the project size problem. I suggested that for large projects, the project owner would write a creative brief, we would work as a team on ideation and story development, and we would include a review process before moving forward. And for small projects, we could skip some of these steps if they weren’t needed.

All projects needed implementation though, and so the next set of steps were copy and content generation, production, review and testing, and launch. For large projects, this part of the process would be based on the brief and story set up already. And for small projects, this allowed us to work fast by jumping into content when we didn’t need a full-blown strategy.

It was important to include a review and testing step in the process for a few reasons. First, it’s often overlooked or cut, and we had run into problems in the past by cutting corners here. Second, it was an opportunity for stakeholders to regroup and make sure that the end result met the requirements. It was important to position the review as ‘Does this solution solve the problem?’ rather than ‘Do you like this solution?” The key to success here was time we spent in the kickoff to pin down the problem. And finally, it forced us to plan for the mandatory compliance review that we always seemed to forget to plan for.

Validation

Once I had a rough draft of this process written up, I wanted to use it on a real project to work out the kinks. Fortunately, we had our 401(k) pricing calculator (definitely a ‘large size’ project) coming down the line to test it out.

So I worked with the marketing director and the head of the 401(k) business to test out these steps. The first run required me to do a lot of the work teaching the team how to form a well-defined problem, helping them to write the creative brief, and tracking down stakeholders and managing deadlines.

One thing I realized I missed was that projects often needed to loop in copywriters, compliance, and engineers, and we needed to be clear about when and how they were expected to be involved. So I included a list of specific people who were responsible for either doing the work or delegating it to their team, and which of these people were required to participate in each step of the process.

Implementation

After both teams agreed to work by this process, I set up a weekly prioritization meeting where there would be at least one stakeholder from each business line, one stakeholder from marketing, and myself. The purpose of this meeting was for each business line to discuss projects they needed in the near future and to make a business case. Once we had the list, we could all prioritize them together, against any projects currently on the roadmap.

The most interesting thing to come out of these meetings was that they were a really effective way for the two business lines’ teams to negotiate priority. There were many compromises made when we actually talked about the business goals of each project objectively. It gave us all a sense of compassion to prioritize together as a team — again, it’s amazing what a little real-time communication among human beings could accomplish.

Iteration

The biggest downside to this process was that it’s a lot of process. It was a hard sell to both teams, and it required a lot of work on my part making sure everyone was following it at first. But I felt it was important for us all to learn the ropes before we made any changes, and I felt strongly that front-loading more of the planning actually helped us reach better solutions.

But after a few months, we all got into a good routine and were able to streamline the process quite a bit. We all got comfortable with the ‘define a problem well and compare the solution to it’ pattern, and we were able to eliminate a lot of people from the initial kickoff meeting and give them time back. We found it easier to designate one point person who would manage all secondary stakeholder input.

Once the team saw that this process was more efficient, they were motivated to provide us with all the right information, and they trusted us to act on that information. We eventually got to the place where the marketing managers and I could sit down more casually and discuss the problem that the product owner and team had already scoped out.

Takeaways

And the end result? Having a team that communicates with each other, compromises with each other, and trusts each other is totally worth the work it took to put the process in place.

• Product Management
• Process

All information in this case study reflects my thoughts and does not necessarily reflect the views of the company. To comply with my non-disclosure agreement, I have omitted and anonymized confidential information.