What we can learn from Product Teams

For many years now, Google has employed an 'Innovation Time out' policy that encourages its employees to spend 80% of their time on core projects, and roughly 20% (or one day per week) on "innovative" activities that are not directly related to their projects but might benefit the company down the road. Some of their most significant advances in their products came from these developments: Google News, AdSense, and Gmail to name a few.

Now, if you were to extend this idea and let entire teams adopt this model of work, well, you would end up with what we refer to as product development teams. With the exclusion of strategic business constraints, one of the main responsibilities of product teams is to innovate and continue to expand on ideas to create new business solutions. Product teams are at the core of the business, and because of this, a lot of the innovative bandwidth of an organization ends up being forced on them. But why? Shouldn't shared learning and feedback be a core component of all teams in innovative companies?

Well, there are a lot of things that product teams do that naturally encourage innovation, many of which are not being used by their non-technical counterparts. So let's dig into what product teams do well, and what other teams can learn from the strategies and frameworks that they use to be successful.

Ah yes, the trendy term you might have heard many times by now.. Just in case though you might not have come across it, the term 'feedback loop' is just a way to define the cyclical nature of things. They exist everywhere, in nature, in business, in human biology, in investing, etc. If you want to learn more on how to structure feedback loops, here are a few books I enjoyed reading: The Power of Habit, Atomic Habits, and The Lean Startup.

In James Clear's short article, he states that "feedback loops are the invisible forces that shape human behavior". By extending this, I am saying that feedback loops are the invisible forces that shape all business behavior. As you will see in all the resources I have linked above, feedback loops are everywhere, but it is how you use them that will determine your success, which is what the best product teams out there have mastered.

There is a natural iterability deeply ingrained into all successful businesses, however, it is important to emphasize that iterating and creating feedback loops should not JUST be for product development teams or strategy decision makers. There is great value in creating a culture of dedicating time to 'retrospectives', which can be weekly, bi-weekly, or even monthly (I tend to like more regular meetings than monthly because new ideas and learnings are susceptible to recency bias) problem-solving sessions where groups of employees work together to come up with creative solutions to problems that they themselves, or their customers/users have faced or continue to face. These meetings aren't meant to give vague suggestions either - they are meant to be specific and actionable. The best feedback loops are ones that can give measurable and comparable results. In product sprint retrospectives, teams go into detail about what went well, what didn't go well, and how they can change moving forward. My tip would be to have a mix of 'senior' and 'junior' people so that there is a balanced dialogue and someone will be able to answer questions like "Why do we do ___ that way?" or "What is the value of this?". It is also worth emphasizing that these suggestions can be for both internal and external facing feedback loops, meaning that product team retros might be more easily quantifiable and user data focused than other teams, but that's ok, the key is to give time to work as a team to 'tweak' your systems.

That being said, this is easier said than done for non-technical teams, as they usually do not participate in structured, reflective brainstorming sessions the same way technical teams do. Technical teams have work that is generally more dependent or closely tied to each other's outputs, whereas non-technical teams have outputs that are generally independent of what their colleagues are doing, leading to individual results and learnings. This means that less collaborative teams will have to get more comfortable speaking up during their time together, which brings me to my next point.

One thing that the best product managers do well, is understand that every individual on their team has so much value and knowledge to bring to the table, so by creating an environment that encourage dialogue, the probably for success is much greater. One of the most overlooked aspects of any successful culture is communication. Without appropriate communication, the so called 'feedback' needed to change will either be wrong or simply nonexistent.

In the book Inspired by Marty Cagan, he consistently emphasizes that team collaboration is key and that the best product ideas usually come from your engineering team. So, by making your engineering team comfortable giving feedback and participating, you are tapping into possibly some of the most valuable pieces of insight about your product/business. The only way to do this is by giving them a platform and creating feedback loops!

This idea does not change for other teams. With the pre-requirement that an organization has done a good job in hiring motivated and willing individuals, I can guarantee that no matter what department you try this in, if you create an environment where the ones who are building your product and interacting with customers are comfortable sharing their insights on a regular basis, you will get the following results:

I contemplated putting this section first, because I believe that transparency is the glue that holds every single idea mentioned in this blog post together. In this Glassdoor article, the team there argues that transparency can benefit your workplace by encouraging communication and sharing, increasing employee engagement and happiness, creating a stronger workplace culture and alignment of values, and as a result, better customer relations. From my personal experience, I feel that transparency is one of, if not the most important factor that leads to loyal teams and a well-functioning business.

I have recently found that a lot of employees leaving negative reviews very commonly complain about the organizations' overall lack of transparency behind their decision making. Whether the feedback directly or indirectly used the word transparency, they all seem to be emphasizing that there are too many barriers between leadership and the ones at the ground level doing the work.

Transparency is a very specific thing that seems to be is deeply rooted in product development teams. If a product manager does not explain to the rest of the development team why they are building something, you could expect to miss out on a lot of opportunities and you will probably have a team that is generally less engaged and excited. Product teams understand that knowledge is power, and the only way to achieve a shared vision is by being transparent, truthful, and open about what the priorities are and how they can work together to achieve desired business outcomes.

The easiest way I thought of conceptualizing this for managers and leaders is to think of treating your employees as if they were your paying customers. If you had 8 hours a day with your customers, would you not want to know what they are thinking? What would you ask them? Imagine how much these 40 hours of feedback would impact your product. Your employees have the same potential energy.

For whatever reason(s), it seems to be more commonplace for technical teams to leverage technologies to streamline their workflows than their non-technical counterparts. That shouldn't be the case. Once teams are stable enough to explore and test different things that will improve overall productivity, it should be prioritized. Whether it is a technology, new process, or even a training, they should always be happening and be readily available to your teams.

As your business continues to grow, there should be a need to foster that experimental mentality of "How can we work more efficiently?" and create a culture of learning. You can't wait for your leaders or managers to make these decisions on their own, you need to open the floor to your team and understand what tools they need to do their best work.

Just because some teams can live out of Google Docs, Excel, and Sharepoint, doesn't mean they should. Look at your product team and see what tools they use. How do they implement them into their workflows? How could you replicate that on your team?

It is important to emphasize that tools are not necessary to achieve more fluent communication and transference of knowledge, however based on the size the organization, budget allocations, geographic locations of employees, and several other variables, they may be more strongly recommended for some over others.

This takeaways portion is really what I have been thinking a lot about lately and is the main reason I wanted to write this blog post. I have recently been seeing a lot of great companies use new, unorthodox tools and frameworks to encourage collaboration and overall company culture. The list below are some of the ideas that I believe most teams and businesses could use to encourage better feedback loops, communication, transparency, and knowledge sharing.

I am a firm believer that every organization should have internal, podcast style conversations, that are not rehearsed, but structured in some sort of way to guide the conversation. If these are done consistently, it creates so many opportunities to learn, adapt, and most importantly, it creates a deep transparency through cross-organizational conversations.

This doesn't have to be leaders or managers either, you could structure it in so many ways to include a variety of employees across the organization to speak about their experiences and learnings.

I would much rather listen to a product manager speak about a new feature for 30-45 minutes, going into the details about their ideation, discovery, testing processes, business alignment, and what they've learned, over watching a 3-10 minute training video on the same feature.

I would also rather listen to my CEO speak with an engineer about developments, upcoming initiatives, and more, over watching a scripted conversation between him/her and an external podcast host.

I could go on for hours about how this would create a more knowledgeable, confident, and most importantly, innovative workforce; so please try this, test it out in small teams first, and see how everyone engages with it. Don't feel like you must have an entire structure from day one either. You can use any video conferencing platform, Loom, Clubhouse, etc.

Unfortunately, this tactic won't create the direct transparency and camaraderie that I mentioned earlier due to it's non-interactive, impersonal nature, however anonymous surveys still work by giving a lot of insight as to what the different members of organizations have to say about their experience. This could be more general questions like "How has your experience been at ___ over the past year?", or it could be as specific as "What are your thoughts on the new sales structure?". There are so many cheap tools out there that could do this for you, like Google Forms, Survey Monkey, Typeform, and Lattice, just to name a few.

This is the most obvious one, but it would probably be surprising to see how many teams don't use these meetings effectively. The key word here is reflective, meaning that teams take time to think deeply or carefully about their work and the business. I already mentioned some of these above, but here are some structures this could follow:

One of the keys for success for reflective learning sessions is to document and summarize the most important/key learnings. From here, you could then tie it back into my conversational outlets suggestion by sharing these learnings with an entire department or across the whole organization

(Also worth mentioning that all 3 of the above mentioned structures are usually implemented by the best product teams)

This is my most non-trivial suggestion because most companies already do this, but it is more about how they are doing it. Building knowledge bases that are organized and very easily searchable is the key to creating extremely efficient teams. Now, I'm not going to go into detail about HOW you should structure your knowledge bases, because that could have its own entire blog post, but what I will mention some of the ideas that have crossed my mind in this regard:

The problem when it comes to implementing all my suggestions above, is that it's not as easy as just saying "every month let's do ___"; it actually requires an entire culture shift. Meaning, it should become a part of the company's values, the job description, heck even somebody's title, to maintain the use of structured feedback loops to encourage iteration and innovation internally. It's really easy to add something like "Creativity and Innovation: seeks new and better ways of doing things, generates original and imaginative ideas or solution" in a job description, but do your teams and company culture truly encourage this?

Thank you for making it this far! Please don't hesitate to reach out - feedback is always appreciated.

shayanmz12@gmail.com

https://www.linkedin.com/in/shayan-memarzadeh/