No process for sharing knowledge. Difficulty getting buy-in from stakeholders. Lack of clarity on what success looks like. These are all common collaboration challenges reported by distributed teams – but they’re also hurdles faced by all teams, particularly as a company grows. We sat down with product leader Sachin Rekhi to discuss what he’s learned about good collaboration as a founder and product leader at companies both large and small.
On common collaboration challenges
What are some of the points in the product development process where collaboration usually breaks down?
There are two challenges I see quite regularly. The first is around company-wide communication and collaboration. As your team starts to get larger – maybe just above 50 employees – you get to a point where a variety of product teams are working on different parts of your product.
You quickly start to lose communication between those different product organizations and teams. It starts to feel like you’re operating in silos. Despite our best intentions, sharing information actually becomes a hindrance, rather than something you’re doing on a regular basis.
How does communication play a part in good collaboration?
When I was at LinkedIn, I had an experience that caused me to start thinking about better ways to communicate cross-organizationally. I started on the Consumer team, working closely with Growth. LinkedIn has one of the world’s best Growth teams, which built an amazing process of running hundreds of A/B tests every quarter and then reporting those results up, building a really strong intuition for what works.
Then, I moved to a new team, and I noticed right away that we kept having familiar conversations we’d already had on the Growth team. The heads of the two teams would meet once a quarter to share best practices in an ad-hoc way. But there were daily learnings that weren’t getting shared. The A/B tests the Growth team were running yielded incredible insights that my new team could have been leveraging.
At the heart of the challenge was the way the Growth team was communicating their insights: they’d send out the results of their A/B tests – with beautiful graphs and whatnot – but the reality was that it got stuck in email. And you had to be on a particular distribution list to even access those insights. This was such a big missed opportunity for insights to be shared on a regular basis across the organization.
Normally organizations say, “Hey folks, we should be sharing best practices, so make sure after you finish a project, create a Wiki page with the best practices that you can share. But because creating a Wiki page is a separate step, it becomes a “nice to have,” not a “need to have.” Sharing best practices isn’t most people’s day job.
The classic ways of solving for this – all-hands meetings – also didn’t solve the problem, because then you get bombarded with information when it isn’t the right time to leverage it. I realized that so much institutional knowledge is never actually shared broadly. That realization was a big part of why we created Notejoy.
On creating a culture of writing and reflection
What are some frameworks or processes for better cross-organizational communication?
At Notejoy, we’re very much a “writing culture” organization. I’d contrast that to a “PowerPoint deck” kind of culture. All of our roadmaps have associated narratives. We actually write our specs as these mini one- or two-pagers that we use to institutionalize knowledge, and we use it as a medium for us to share with each other and get feedback. It’s also a great way to look back and see what’s changed in our thinking.
We have a whole set of templated documents that we use for various aspects of our process.
We have a quarterly OKR review, and all those live inside of a note and notebook within Notejoy. Our quarterly roadmaps also live in there. And we do quarterly business reviews to postmortem the quarter and look at what worked.
None of these documents are more than a page or two. They’re very lightweight. But we find that having a structured process has enabled us to capture a lot of insights – but then also to make us more reflective. A lot of the value of capturing those insights is simply looking back and seeing what we can learn.
It’s easy to think about all of these documents that you’re creating as waste, like, “Oh, why don’t we just get our job done instead of writing this all down?” But when you bake it into your process, improving next quarter’s roadmap based on the learnings from last quarter’s documents, you start to feel like it’s not a waste of time. It’s giving you better insights than what you would have gotten before.
A writing culture sounds like it would be great for distributed teams. How do you ensure everyone’s voice is heard?
I think that it’s important to not just treat these documents as one-way conversations. You need to make them interactive, as a way to really involve the other person. Encourage comments. As soon as comments are added, respond to those comments. Provide your perspective. That recreates that in-person watercooler, or the feeling of being able to walk to someone’s desk.
Our current team Notejoy is not distributed, but we’ve still leveraged a writing culture. When you are able to send someone a written prose narrative, it allows them time to think through it, and then to respond. You can have a much more interesting dialogue.
How do you figure out what works and doesn’t work when you release a new product or feature?
We do retrospectives on a quarterly basis. This gives us enough time with the features being in market to really understand if they’ve had the impact that we expect. Part of it is assessing the typical engineering perspective of whether something took longer than expected (and why), but we’re equally (if not more) excited about looking back at whether the project met our business goals.
Every project usually is associated with one of our key metrics around acquisition and monetization or engagement, and we ask ourselves, did we hit the objectives we were trying to hit, and if not, why not? Oftentimes, it’s most useful for just building calibrations: When you launch this kind of feature, you can expect it to have this kind of impact on one of your core metrics.
If you’re not doing regular retrospectives and looking back and really seeing what was accomplished, you’ll never build that product intuition of what actually works, what can you expect to move the needle, and what never moves the needle. Without that, you never actually build the product intuition that allows you to make sound judgments going forward.
On a product manager’s role
Do you have any tips for how product managers can work well with collaborators, like UX designers?
This is the second collaboration challenge that I was alluding to earlier. As a product team, you want to move as fast as possible to deliver delight and great user experiences for your customer. But it turns out that there really is no substitute for creating shared context amongst the team, and to be really effective at it.
I talk a lot about the value of influence without authority. You can’t just tell the team what to do, because you don’t really have the authority. You have to influence them. It really boils down to the art of making a compelling argument, and then using that to bring everyone in the organization along.
I wrote a blog post about the six elements of style around making a compelling argument. To be compelling, you need to think through your target audience, and figure out what’s the most compelling way to make a compelling argument to them. Everyone is different. Some people are really moved by data and metrics. However, lots of people aren’t that way. You give them data, and they will be skeptical. They’re more moved by individual anecdotes and stories of real customers. You need to understand the right approach.
Elements of style of a compelling argument
Framing
Inception
Social proof
Citation
Goal seeking
Narration
What is one thing you know now that you wished you’d known back in the beginning of your career?
One lesson that I learned the earliest was the most impactful for me. Initially, when I thought about product management, I thought about it in terms of hard skills: writing product specs, doing customer discovery and research, being analytically rigorous and tracking metrics, prioritizing a roadmap.
But I ultimately realized that while hard skills are 60% of the job, 40% is soft skills: influence without authority, executive communication, being a great collaborator, having high emotional intelligence. It turns out that product management is a leadership role. Even as a junior product manager, you’re working in cross-functional teams, helping to push forward a product in the right direction.
