5 minutes read

Working with Product Teams

For last few weeks, we are working with an early stage Silicon Valley startup. The founder has worked at Box, Microsoft, etc and this is her second startup. She has an ample experience doing Product Management.

She has never outsourced product management before so she was quite skeptical. Her major concern was onboarding a team sitting in India (10,000 miles away and working in diagonally opposite timezone), making them own the product vision and getting desired rhythm with daily progress.

All my initial conversations with the founder reaffirmed my belief that for any startup,

“Time is the most important asset and progress is the only thing that matters.”

We have been working from India with startups in different timezones from day 1.  So these concerns were raised to us by many founders in past. I gave her a few suggestions to work with (any) Product Team to achieve desired rhythm. They are worth sharing so here they are!

Keep passing product vision to the product team and keep them on same page.

This advice is similar to what Fred Wilson has shared in this epic post.

Why?

• Clear product vision will drive all the efforts in one direction (right or wrong, nobody knows till the product hits the floor!).
• What problems is the product solving?  Who are the users of the product? How are we going to measure the success of product? Constant iterations over such questions will help team stay focused on making product more usable.
• Being on the same page ensures a greater transparency, participation, product ownership and shared pride over period of time.

How?

• Founder needs to have clear written documents like Lean Canvas, User Personas, Site Flow Diagrams, Wireframes, User Stories, Important Metrics. These documents forces founder to have better clarity herself and it trickles down to product team, which is their number one demand.
• Founder should at all the time proactively and consistently, while discussing requirements, writing an email to client / team, resolving conflicts about priority, standups, retrospect, planning meeting etc, pass vision with right context. Team will see your passion about the product and connect with the product and passion over time.
• Team should connect with vision from day 1 and own it over time. If you are not convinced of the product idea or some features, learn more about the product by asking right questions. This is how you work as a partner and not merely as a vendor.
• Everyone should constantly keep user, problem and priority in mind while writing a user story, developing a story, fixing a bug, designing a feature, deciding approach to the problem, launching product and doing almost everything.

Have the most effective collaboration.

Why

• Product development is a collaborative process. Founder has to constantly collaborate with users and the product team to make it a success.
• The people on team come from different background and bring different expertise, so effective collaboration can lead to a much better outcome and vice versa.
• The expertise is spread over the globe, so we may have people working in different timezones.

How

• Be frank and open in communication. It’s okay if the deadline is not met but it’s not okay to hide that. There can be legitimate reasons for missing deadlines. But yes, team should be committed to improve and not make same mistakes again.
• If you are working in different timezones, have at least couple of hours of overlap.  Product Team should be available at that time.
• Give flexibility to team members in terms of working remotely if need be. Provide required infrastructure for the same.
• Have right tools setup for each purpose. We use Trello for Product Management, Google Drive for Document Exchange,  Mattermost as communication channel,  Gitlab for source code management,  Emergency communication call on mobile number, etc.
• Set a weekly rhythm and both parties should commit to it.
  • What is the progress we made last week in terms of product? Celebrate the milestones.
  • What went wrong in last week?  Understand the reasons behind them.
  • What improvements do we need in next week?  Ensure a quick course correction.
  • What is the plan for next week? Where do we see the product at the end of next week? (A Sprint Goal.)
• Set a daily rhythm and both parties should commit to it.
  • Is my yesterday’s work committed, reviewed and delivered?
  • Do I have a clear work for today?
  • Do I need any help from anyone to achieve today’s work?

Making progress every single day.

Why

• Time is the most important asset. We need to use it in the right direction.
• Wasting time means increased cost and lost opportunities. Time spent in the wrong direction or waiting is time wasted.
• Due to dynamic journey, startups require path correction and re-prioritisation on even daily basis if need be.

How

• Define and understand progress clearly by acceptance criteria / definition of done. I want to see this happen by end of day, week or month.
• All Devs and Designers should measure progress end to end, it is never done when it works on your machine, it is only done when it solves the problem for users.
• Look at the progress with right context. It may be taking time due to existing code base,  lesser clarity about product, ramp up time on technology and codebase.
• Take corrective measures for better progress tomorrow, next week or next month. Be it pivoting the offering, raising funds quickly, removing a misfit from team, etc. If things are not working you may have to close the startup as well.
• Convey your progress and problems clearly and honestly to the team as it helps to decide next course of action.
• If stuck up in one area for a long time, seek proactive help and remove wait or hold. It is okay to seek help. We do not expect you to be master at everything.
• Be ready to change, throw and redo anything. Startup lifecycle is inherently dynamic, forcing not to change is a death of startup.

So, this is the gist of what I have learnt so far by working with numerous startups (and launching some of our own) over last 13 years.

I would love to hear your suggestions on how to effectively work with Product Teams.