How to bring technical and non-technical teams together

March 24th marked our first official (and virtual) Release Event. We showed off new features like Teams and our upcoming Productboard Integration, shared great insights and best practices from Shortcut customers, heard our CEO's vision for the future of Product Collaboration, and showed off some of the exciting things that are coming to Shortcut in 2021.

One of the customers we heard from was Mansi Kothari, the Product Lead at Maven Clinic. She spoke with Heather Purdy, Group Product Manager here at Shortcut about how she builds a shared product vision between the technical and non-technical teams. Mansi is uniquely qualified to discuss this topic as she was previously the Director of Product Marketing at Maven before making the move to Product.

You can watch the recording of her 30 minute session below and read the key questions and points from her session below that.

Can you tell us a bit about your background?

For a long time, I’ve been a stakeholder in product strategy and planning. I’ve worked in Content Development, Strategy & Operations, and Product Marketing across a range of growth-stage companies. I’m currently at Maven Clinic, a B2B2C digital health company for women and families focused on critical stages for starting and growing a family: Fertility, Maternity, & Early Pediatrics.

As the head of Product Marketing & Research at Maven, I led processes to better understand user behaviors and the competitor landscape, in the discovery phases of product development. I also led processes for bringing the story of our product into the market and building feedback loops from users.

My new role as a Product Lead at Maven allows me to shift gears and focus on that middle phase - taking user and market inputs, as well as internal stakeholder perspective, to develop a product plan and deliver on it.

Both of your titles have the word “product” in them, but they have very different responsibilities. What are some new challenges you face leading a Product Management team?

Prioritization! The possibilities are endless but the resources are limited. I have to let go of focusing on every little nit with the user experience and really ask myself what will deliver the most impact.

Inspiring a team that I don’t directly manage, with very different skills and a different set of information than my own. It’s about building shared context and mutual respect for each other’s craft.

Now that you’re a Product Lead, is there anything about your prior relationships with Product that you see in a different light? Advice you’d give your past self?

Business partners should focus on sharing problems instead of solutions.

In my past role, I tended to give product feedback in the form of solutions, which was always frustrating to Product Managers who wanted to better understand the underlying problems. Now I recognize how important it is to clearly articulate the user problem - that’s what’s most helpful to hear from stakeholders; leave the solution itself up to Product & Engineering because you might not know how much work is involved in your solution and if there are lower-effort options available. That doesn't mean your solution isn't the right one, there's just no way know without fully evaluating the problem.

To use a potential problem and solution at Maven, instead of saying, “we should build a feature for users to DM other users who are expecting on the same due date,” reframe your statement into the problem: “users who are pregnant feel isolated during the pandemic and wish they could connect with other users with shared experiences.”

As Product Managers, the relationships we build with stakeholders are incredibly important.  What are some ways you’ve found that help build those partnerships?

Product should make sure that business partners have a voice and seek their input on product strategy!

On a more informal level, there’s often room for Product to do a better job of making sure that they are creating space for internal feedback and incorporating it into their backlog on an ongoing basis. Product shouldn’t feel like a black box.

Encourage coworkers across the organization to use the product! Cultivating internal utilization of your product is one of the best ways to make sure you stay in touch with the user experience!

Some ways we’re doing that at Maven include: an open #product-feedback Slack channel for employees across the company to share their feedback, internal user testing for lightweight features, aligning product strategy with company strategy, and engaging key stakeholders in our roadmapping process.

How did your experience in Product Marketing shape the way you approached roadmapping?

Having worked for the past year on leading user and competitor research and partnering with our sales and operations teams so closely, I had a really good understanding of business performance, user pain points, market opportunities. I took the time to kick off roadmapping by setting the context for the rest of the team by explaining performance of each of our product lines in generating revenue for the company, how our product compares to the market and key areas where we can better support users, including a review of user engagement data. This empowered the Engineering Team with the information they needed to voice their opinions on what should go on the roadmap.

I also did a complete audit of our product and developed a comprehensive shared team backlog of product opportunities - each opportunity included a problem statement, description, potential impact, T-shirt size, and required Engineering resources. Going through that exercise made the roadmapping process much easier because we already had a list of ideas to pull from.

Now that you’re a Product Lead and own the product roadmap, do you view the roadmap building process any differently?  Did anything surprise you?

How much work and relationship building goes into getting buy-in across the organization! The work that goes into even seemingly simple changes can be a lot more complicated than they seem at face value. For example,

I was speaking to a backend engineer yesterday about a seemingly simple update that involved modifying the logic to determine whether to display a certain feature to a user. It turns out that the code for that feature is currently living in different places across the codebase, so to update the feature, we first need to consolidate the code.

A good PM needs to be able to communicate very clearly to others why and how they’re prioritizing what they are, and what the tradeoffs are. They should always assume that business partners don’t have the same information that they do about what’s technically feasible vs. not.

For example, something we want to tackle more deeply this year is product personalization to different user personas. This is a very large project. So we need to figure out all the places we can personalize: emails, dashboard, content library, care team. And then we need to pick a place to start that feels like the lowest hanging fruit. Sending data about users to our CRM to automate which emails they receive is a good starting point to test and learn before we personalize more deeply in the product.

At Maven we have a digital app and an in-house team of Care Advocates that provide human support to users enrolled in our Product. When we want to experiment with a new concept, such as a new iteration of our user onboarding experience, we might test through our Care Advocates first (without Engineering resources) before investing in an in-app approach. Business partners are really helpful in brainstorming and implementing those operational solutions.

Here at Shortcut we’re always thinking about how we can better help teams to plan and communicate the progress of their work. We’re sharing today a number of new features in that space.

How does your team use Shortcut today throughout the planning process?

Shortcut is the source of truth for our Engineering team, representing the work that’s slated for right now, what’s on deck, as well as bugs, tech debt and UX quality tickets that we can pick up along the way. We represent projects on the quarterly roadmap as Epics, broken down into individual stories, and prioritize stories into 2-week sprints via Iterations. We use it to measure and understand where we missed our targets and why. So it’s a really critical tool for that medium- and short-term planning, and perhaps long-term too as our processes evolve!

One top of this, we use Shortcut to collaborate across Product & Engineering pods and work through dependencies. We also use Shortcut to interface with our Data team, to do things like launch A/B tests, set up event tracking, and measure success of new projects.