All related (20)
Rosa Villegas
Senior Director of Product, Central Technology, ZyngaAugust 1

Be adaptable to change - don't be afraid to try different things or change a process that is no longer working for the team. For a team that is growing quickly oftentimes process gets ignored because the team is so focused on delivering/executing that they feel process may slow them down. In some cases little to no process can be a good thing, but for a team that is scaling it can be detrimental. What I try to do is understand how they are using product management processes today and then try to understand where product can add the most impact short term and demonstrate early wins to help build trust. Getting buy-in from the team is essential, and typically I try to message that I am adaptable and my goal is to help the team's ability to execute and focus on the right things rather than add more things to their plate.

I entered a team that was doing well from a revenue standpoint but was constantly putting out fires and as a result didn't have much time to focus on feature development to improve and grow the product - it was just maintaining with a bit of decline. I focused first on root cause analysis of the fires/incidents from the previous 60 days and found most of them could have been avoided by introducing a lightweight process before a content release. We piloted it for 1 team for couple sprints and found it reduced incidents by about 50%, so we rolled it out to other teams and got similar results. This in turn freed up engineers from firefighting, and also helped me build trust with the team. In general my motto was "what we have now isn't working, let's try X for a few sprints and if it's not working we'll try something else." The general pushback I usually got was from engineers who wanted to avoid meetings or unnecessary overhead - however, I found that if I could show that I was flexible and what I was doing would ultimately save them time/effort, I found most to be amenable to change. 

Another tool that helped me was retrospectives and post-mortems, and advocating for better processes during these times. Oftentimes in these situations people are open to discussing improvements, and if you can clearly tie in how a product process can help avoid/solve a problem you can get buy in easily, particularly if you are offering to drive it. Better yet, if you can circle back with results and outcomes that show how this benefited the team (fewer CS tickets, better velocity, etc) you can help demonstrate the value that product can provide. 

Janet Brunckhorst
Director of Product Management, Aurora SolarOctober 16

I'm a strong believer in "just enough" process, so my answer to questions like this is always some version of "it depends"!

The one piece of process that every team must have is a way to reflect on, and incrementally improve, they way they work together. You can call this process whatever you like - "reflection", "retrospective", "after-action review", "post-mortem" - but it is imperative to building an effective team. 

This practice will inform the way you introduce and evolve processes as your team grows.

Here's the lightest-weight retro format I've ever used, which is a great way to get started:

Format: individual stickies brainstrom (one idea per sticky)

Time: 30 minutes to one hour

Frequency: Every one to two weeks


  • Each person responds to the "I like" and "I wish" categories on individual stickies - timebox to 3-5 minutes
  • Each person shares their stickies
  • Affinity mapping: cluster similar ideas together
  • If needed: dot vote on the things that are most important. Be careful not to always prioritize the concerns of one group, though (eg, if there are more engineers than any other role, how will you ensure you also address concerns from other roles?)
  • Discuss your highest priority topics, with a focus on understanding the cause and generating ideas to make it better. Retro isn't a venting session!
  • Agree on the things you'll try, and if appropriate, who's responsible for making it happen.


  • I like - the things that worked well in the preceding week or two
  • I wish - the things that you wish were different
  • We will - the group's commitment to change over the next week or two

There is literally an entire book on this topic: Agile Retrospectives, by Esther Derby, Diana Larsen, Ken Schwaber.