How to Setup Product Teams for Success

Having led and observed product development initiatives that took years to launch (IBM’s clients, Dun & Bradstreet), quarters to launch (, and months to launch (,  DreamIt Ventures), I’ve been amazed by the productivity of small product teams.  The article about PayPal’s reinvention being powered by small product teams, and of Shutterstock’s success being driven by small product teams, comes as no surprise.

If you want a high performing growth company, small teams (typically up to 15 people) is not the only answer.  Small teams need to be setup right, with the 4 R’s.  They need the Right People, Right Problem, Right Processes, and Removal of All Friction.

Right PeopleThe highest performing product development teams I’ve seen have a mix of skills and attributes.  They have someone quantitative, someone logical, someone collaborative, someone artistic, and someone good at user experience. They typically include a full stack of engineering capability, design/ux, a product manager, QA, and part-time marketing insight.    On some teams, design and QA can be part time, but once the changes get frequent enough or opportunity is great enough, it becomes very helpful to have both full time if you want more cycles of work released faster.  Teams running without design or QA can’t iterate as quickly and are likely mis-using precious development resources, or not allowing the product manager to stay one step ahead.

Right Problem.  The highest performing product development teams are focused on the right problem.  Typically, it’s quantitative.   Low performing teams often have feature launches as goals.  It’s too hard to judge success of feature launches, and they don’t drive business results.  Launch gets delayed because what matters is how good the feature is, not what results it drives.  Resources get allocated to a part of the feature that does not drive business results.  Another indicator of low performing teams is a lack of focus on a single problem.  If there is not a single job to be done, the team loses focus.  If the problem changes to often, there is not a chance to learn and improve. The right problem also motivates the team and provides a rallying point.

Right Processes. Teams need to find what keeps them humming.  I’ve seen KanBan work great for very small product teams, as engineers can easily see what everyone is working on and, once finished, pull the next thing off the queue.  Agile works well for larger product teams and projects, as the daily stand-up provides a rhythm and sense of shared commitment.  Both of these processes focus more on productivity than on overhead.  It’s important that the process not require much time spent providing progress updates and deadline estimates, as time spent on these activities doesn’t produce a better outcome faster.  Even when working with an outsourced or offshore team, I’ve found KanBan to be better than requirements documents.  Development processes also matter–how is code controlled, how is testing done.  Teams need to optimize (or ideally eliminate) each step in their processes.

Remove All Friction.  Ensure the small teams are not dependent on another team to get something done–put as much as necessary in the team’s control and allow them to work on the end-to-end solution.  Try not to have the team dependent on a shared resource, for which they must spend time queuing or requesting.  Provide all the resources they need, whether it’s software, testing devices, or stock photography.  Organizations of any size have people or processes that create friction.    Keep obstructions such as management requests for status updates or reviews to a minimum, or at the very least  focus them on a single team member.  Give the team goals and not flagpoles, as each flagpole introduces friction and delays progress.

If you follow the 4 R’s — Right People, Right Problem, Right Processes, and Removal of All Friction — your product teams will be motivated and set up for success.

Did you like this? Share it:

Better Product Management: Goals and not Flagpoles

Getting a sign off and blessing on a project

Requiring blessings and approvals delays hitting goals and devalues customer validated learning

As a manager, do you feel the need to control every resource and every action of your employees?  Do you want to know everything that is going on–and not just whether goals are being hit?   Do you put in place requirements for sign offs? If so, you’re likely get suboptimal performance from your team.

Often when mangers seek to control a process or know what’s going on, they introduce a sign off requirement.  Time spent getting approvals delivers little value unless it results in very meaningful change.  Instead, this act of ‘running things up the flagpole’ and ‘getting the Pope’s blessing’ mostly delivers value to the micro-manager.  Even if going up the flagpole changes the result, it’s often highly likely that both ideas we’re right–and no customer validated learning occurs to improve future decision making.

Recently a new product management process was provided to our team.  If someone wanted to start work on fixing a high priority bug–even one that affected 50% of online revenue, they would need to get 2 sign offs and alert a third person before work could begin.  This “flagpole” upon which a new activity needed to be run up and approved–provided transparency and control over resource allocation.  However, it means that bugs stay on the website longer, more time is spent getting sign offs, and less time is spent delivering value.

Another example is spending hours getting  approvals for website copy.  After 6 people spent about 6 hours each on copy, another 9 people spent two hours and a half hours in a room approving the copy.  Over 50 hours were spent on copy. The time would be better spent ensuring there was an A/B testing platform and regular usability testing.

Even a customer service organization can create the flagpole problem.  For example, often customer service representatives are required to get approvals for customer refunds.

A high performing company –without flagpoles–could solicit ideas in under an hour (instead of 50 hours), a/b test a few variations, get qualitative insights from usability studies and customer service feedback, and adapt on the go.   Ideas for copy from the 9 people could come via informal 5 minute meetings or emails.  The product manager would be learning faster, the results would be better and more repeatable, and 45 hours would be saved.  Another process done at one public high growth technology company is to have a daily 30 minute meeting with the most senior marketing person where they can provide input on anything launching–and it’s clear that they’re the gate preventing launch so it usually happens in a few days.

Perhaps most importantly, a flagpole process is not scalable.  A high performing 300 person or 1,000 person company should have too many website updates launching each week for 9 people to sit in a room debating for hours on end.  While it’s helpful to have some tone and style guidelines that fit the brand, long meetings for copy approval are not sustainable.

How do you avoid flagpoles?  Give the product manager measurable goals that are NOT just launching features.  The primary question is where are things tracking toward the goal, and what are the next few things being tried to hit the goal. With goals, it also becomes clear what matters more.  For example, if the goal is a conversion rate, the manager can focus on the emailed or verbal copy suggestions that will be seen by 95% of the users–where someone else in an approval meeting might spend precious time on the copy only seen by 5% of users.  And the answer is which copy converted better, not which sounded better (assuming it’s on brand).  With a goal of a conversion rate, the manager can also decide if the bug fix is worth the engineering time and disruption to hitting their goal. Of course, goals are not everything–for example, a product that grows revenue in the short term might hurt the brand and revenue over the long term–but they are very helpful.

Even operations teams can try to remove flagpoles.  For example, to remove flagpoles in customer service, consider allowing representatives to issues up to a certain dollar amount (e.g., $100) to streamline operations (credit to Tim Ferriss for this idea).

As you run your company, watch out for new processes that require approvals, as they can meaningfully slow down progress towards goals.

Did you like this? Share it: