'Move Fast' - One Product Manager's Best Practices

I went on Maternity leave 2.5 months ago, so far, I found it to be a good opportunity to reflect, internalize past lessons and grow by the affordance of being able to step back. While I spent the last 2.5 months raising a newborn my mind was still buzzing with thoughts about work, life, product management and growth. Staying true to my Amazon training, putting things in writing helps me organize and internalize thoughts better.

I was asked a few months ago how to encourage a product management professional like me to put my best practices on paper to help others in the field. I realized that the barrier to this personally was: 1. Time - I have a full time job and 2 small kids, would I be able to consistently create helpful content for my community? 2. Perception - Will me opinions (as a very direct and passionate Israeli) resonate with others? I'm going to try to do the best I can on both and adjust as we go - please feel free to share your kind and positive no judgement feedback ;)

The first topic I was reflecting on is often top of mind in leadership discussions, which is 'move fast'. Truthfully, this one created an internal conflict for me. Throughout my career a common feedback I received was to 'not move as fast', signaling me to remember to slow down to bring everyone along. As an org leader, I now often hear questions on 'how can we move faster across orgs' which provided me an opportunity to reflect on the drivers for both and the practices I've seen to work to address these constructively.

The 'why' behind 'move faster/slower'

Analyzing the reasons behind both feedbacks, I realized the following:

'You're moving too fast - slow down' - this feedback was given frequently earlier on in my journey when there was missing organizational alignment that came to light when projects where in flight. Being Israeli, the value of agreement and disagreement isn't that different in my culture, and conflict isn't stressful. As such, earlier on I felt that getting the working team on-board is enough, and spending time making sure everyone across the company is on-board is less critical. What I failed to see is that the earlier cross organization alignment can save a lot of time and hurdles later on, opening doors for the team, helping them in reality move much faster. My advice here is to spend as much time as needed making sure key stakeholders are on the same page with you - decisions are cheapest when done early and grow in cost as time progresses.

'We're not moving fast enough - how can we move faster' - often times as companies grow it may feel like larger teams accomplish less - partially since the system is more complex and there are more considerations to think through, and more broadly due to alignment - the more stakeholders there are the more alignment needs to take place, the more processes exist to ensure execution and the more differing incentives exist across teams. However, those things can be broken down and teams can still operate fast in a complex environment, here are my personal tips and tricks I've seen to work -

The 'How' behind moving productively fast

These are the things I found useful and have not seen in other 'best practice' articles, I chose to focus here on items product managers can implement themselves and purposefully stayed away from possible tips and tricks within other functions. To keep things interesting, I'll admit in advance - you might find these controversial, I can only say these practices work for me and it's never black or white, other things have to fall into place for things to work smoothly and there are consideration I didn't cover here (end of disclaimer). I hope you find a few of these useful and try it yourself!

Tip #1 - "Ensure everyone fires in all cylinders at all times" -

• Product managers build the roadmap for their teams. I found that breaking down this roadmap to the expected development work week by week per engineer for a quarter out can be extremely helpful to PMs. The roadmap is NOT there to monitor eng work - but to ensure product and design are ready with everything needed ahead of eng work. Given this, the roadmap is ever adjusting, with timelines expanding and contracting based on eng execution as eng sees fit. Why this matters? Knowing when an initiative is going to start being developed lets PMs plan for when they need to create detailed initiative description, paired with user stories and acceptance criteria along with designs that were groomed together with Eng and Design. When collaborating with product managers, some are surprised by the depth of edge cases and possible errors I ask about when walking through a spec, for me - the level of detail in these specs is critical. Why? If the details aren't thought through in advance, they will come up during development, at this stage the engineer writing the code would have to pause and play product's role - circling back with the PM and design on what to do in the discussed use case, which may result in additional questions to other groups such as trust, infosec or legal as an example. This time prolongs development and adds context switching for engineers moving to other items while questions are worked through. I've seen teams move 2X faster when spending sufficient time writing and grooming requirements that are ready well ahead of development start.

Tip #2 - "Start with yes" -

• One of the most common things product managers discuss is the importance of prioritization, what to say yes and no to, in order to create focus. While I agree this is important, I learned to also value the 'power of yes'. I shifted my mindset from saying 'no first' to 'yes first' a few years ago. The transition at first was in my words, which then translated to the way I was approaching problems and thinking through them and then to outcomes. I started thinking of solutions and how we can make things happen, vs why they weren't a good idea or how we didn't have enough capacity. I witnessed that the culture I create together with my engineering counterparts is critical to the capacity of our teams - when we start with yes - and I have the very unique fortune to work with engineering partners that only start with yes today - there is a natural mental space created allowing the teams to spend time on finding solutions to how to make things work, vs why things can-not work. I often find the discussion around this topic to be controversial - I'm not blind to the 'quality/scope/time' triangle, however - I deeply believe that 'culture eats strategy for breakfast'. Good leaders inspire 'can do' solution oriented attitude that creates capacity for their teams, celebrating this culture and team' success reinforces this loop. Does it mean we never say no? no, we just say 'yes' much more often than 'no'.

Tip #3 - "The portfolio approach" -

• I spent some of my career in account management and sales, a best practice I learned there is to have multiple balls in the air at all given times. Lets say you're looking for a customer to buy a SAAS product - you have a certain conversion funnel that dictates how many leads you need, to close that coveted buyer. While 'spray and pray' isn't a winning strategy, having only few main bets for a lead is also not great. There needs to be a balance of knowing your conversion rate, understanding things might not go according to plan and placing several plays in parallel. Product management is not different. We can estimate impact rigorously, do competitive and customer research to understand the right Jobs To Be Done to de-risk a product launch, but ultimately not all bets pay off. Similarly to sales, in product too, I look for several directions to bet on - lets say for example I want to move a metric like sign-ups - there are many levers I can pull - paid marketing, partnerships, SEO, multiple funnel optimization opportunities, branding campaigns and more - at which point there's a natural Q of - "what should we focus on?" - my answer - "not one thing". This answer differs based on amount of people and teams that can work on the problem - a start-up would naturally have less resources and budget than a larger company. However, in both start-ups and large companies the argument of 'focus' would come to play, and naturally it would be hard for us as leadership teams to focus on a large portfolio of opportunities driving us to encourage our teams to 'focus'. There's a lot of value in focus and at different stages of companies, focus on the right things is what can make or break a company. However, not all decisions are 'make it or break it' (2 way doors) and in surprisingly many instances there are large enough teams where having more or all individuals work on the same focus/initiative isn't accretive to the solutions' acceleration. My approach here is - 'portfolio'. I learned that placing multiple bets, then testing as fast as possible to see what things would pay off and doubling down on them while dropping those that didn't has the most upside, helping to parallelize investments and diversify growth channels. Pivoting teams from focusing on one thing to empowering them to work on multiple projects assuming you have the needed team sizes (see tip #4) also provided the unexpected benefit of creating a more inclusive environment. When sponsoring and focusing on one main project - the unexpected outcome I experienced was that some teams felt excluded or not important, while others decided to join the main project although that did not have positive ROI. Empowering teams to move in parallel on different bets stressing all are important as long as it helps the True North we're marching towards - helped elevate some of these issues.

Tip #4 - "Smaller teams move faster" -

• Amazon's '2 pizza teams' won fame in its earlier days for their executional velocity - the rule simply stands for the size of a team needed to execute on a project where the best team size is one that can enjoy a dinner of 2 pizza trays - if you need more - you have too big of a team. As companies and individuals grow, they often see HC as sign of success; I haven't experienced an annual planning cycle where teams have the affordance to ask for HC and don't. When HC is asked for new projects and capabilities - expansion is good but the important thing to watch out for is - how efficient that additional HC would be across the company overall. I'm a believer in lean teams. When serving as the Head of product and design at Lending Home I had the fortune to launch a first of its kind marketplace helping real estate investors find investment opportunities. Our resources were limited, and time was precious given the stage we were in. We were able to launch a fully digital property marketplace AND a process to vet the quality and price of each property AND find and close 15 transactions end to end AND provide financing for these transaction AND sign agreements with several strategic partners in a mater of a few months. Size of team? 1 PM, 1 Designer, 1 Sales/Loan closer, 5-6 engineers, etc. We had many additional cross functional partners and took help anywhere it was offered but every function had largely just one main stakeholder. We each did a lot. As the exec sponsor for the project I did whatever was needed from signing partnerships to negotiating deal prices to reviewing legal contracts to signing off on mocks, to getting budget from the board to get the project off the ground and running. So did everyone else on our core team - whatever was needed at each stage - we all jumped in. All you need is a small team with a strong entrepreneurial spirit. You might dismiss this as a 'start up experience' - but this was not my experience - I had the fortune of launching Audiobooks on Kindle Readers earlier in my career at Amazon. Our structure was similarly lean - I was the only PM on the audiobook side - overseeing everything related to shopping, consumption, payments and integration of audiobooks into the ecosystem. I had wonderful counterparts to help on the Hardware side and Kindle eBooks side (just one for each), and we were able to move fast together. I find lean structures work better - they allow for focus, fast alignment and easy connection of dots. Amount of HC isn't a sign of success - it's a cost to justify.?

Tip #5 - "Minimize change requests" -

• Any product manager who worked on a big 0->1 project may have often encountered the process of having a polished well reviewed product come to an exec review to have their dream of a smooth launch 'altered' - new information may have come to play, the feel of the product might be different when experiencing it than expected when the mocks were reviewed, the company might have shifted to a new direction that now needs to be incorporated into the vision or a new and exciting idea was raised by a passionate exec. These are all great, but all you can think of is 'omg, the timeline! What about the timeline!'. You're not alone. This is what I found to be useful mitigating methods: 1) Align on a RAPID model and stick with it. 2) Have a regular practice where any feedback provided in the review is summarized by you, following the meeting within 3 working days, send a summary of all feedback color coded - Green/Yellow/Red to stand for - will do before launch, might do if time allows, and won't do for initial launch. Once the process is established individuals know to expect it and trust you to manage it, if they have concerns - you will hear back. I don't recommend opening a debate during the meeting on this - go back and do the due diligence on what's possible, this is usually done better offline. 3) Know surprises will come - plan for it in your timeline and have buffers to accommodate for change requests. 4) Prepare the team throughout the process there will be change requests - when they know what to expect, they prepare for it and aren't surprised when these come.

Thank you for reading and best of luck in your journey, if you have additional tips&tricks - I'd love to hear those!

#productmanagement #movefast #bestpractices #growth #leadership

Opinions are my own only!