{"id":12773,"date":"2017-06-05T20:34:58","date_gmt":"2017-06-05T19:34:58","guid":{"rendered":"http:\/\/blog.intercom.com\/?p=12773"},"modified":"2020-07-30T12:57:56","modified_gmt":"2020-07-30T11:57:56","slug":"what-to-do-when-your-startup-needs-program-management","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/what-to-do-when-your-startup-needs-program-management\/","title":{"rendered":"What to do when your startup needs program management"},"content":{"rendered":"

Shipping product is quick and easy when you\u2019re in a small startup, but what happens when you have a massive team with too many cooks in the kitchen or if there\u2019s one too many delays with product launches? Can your company handle such a situation?<\/p>\n

Many startups hire for project or product managers, but at some point they should be thinking about program management, bringing on people that can help them manage all the moving parts of a complex release. Complexity comes with scale, regardless of how hard you try to fight it.<\/p>\n

Determining the right time and the best approach for introducing program management can be confusing. But when you do, it can mean the difference between a product launch\u2019s success or failure, whether you can deliver on your company goals or not.<\/p>\n

Startups get complex<\/h2>\n

My colleague Mark previously wrote about how focus leads to silos<\/a> as a company scales. Inevitably there are times where you need to build bigger features, launch a new product, or make an update that will impact more than one of your products.<\/p>\n

Our principles of scoping small<\/a>, shipping frequently<\/a> and executing to six-week shipping cycles<\/a> breaks down during these times, as we discovered when launching a brand new product, Articles<\/a>. With more than 45 people across multiple teams and two continents needing to work together in lock step \u2013 this suddenly involves more than just shipping good product, quickly.<\/p>\n

How do we retain our culture and fluid ways of working while avoiding chaos?<\/p>\n

Besides building Articles, the product had to be set up for market success. We had to give customers an awesome first experience using the product, with updated support docs and videos, as well as figure out how the product would be packaged and priced. In total, we had three product teams, marketing, sales, customer support, communications, growth and product education working on it across Dublin and San Francisco. This required a level of coordination that we never had before.<\/p>\n

The challenge is in how we retain our culture and fluid ways of working while introducing just enough structure to avoid chaos. How do you keep the process lightweight enough to add value without adding a bunch of overhead to product and engineering managers and wasting their valuable time with additional meetings, documentation, etc.?<\/p>\n

What we learned<\/h2>\n

Launching Articles was the first time we trialled program management \u2013 we had already missed two launch dates and the team was feeling the pain around the scale of delivery. It was initially thought of as a three-month project but ultimately took over a year to get to market. We underestimated what was involved in building and delivering this product.<\/p>\n

We\u2019d seen this problem before \u2013 we launched our new Messenger product a few months prior and, while estimated to take a few months, it lasted more than a year. I joined the Articles team as program manager about a year into the project, following a second launch delay. There was a lot needed to get everyone on track and motivated to hit our third launch date.<\/p>\n

Clear responsibilities<\/h2>\n

During my first week, I spent more than an hour with 16 people, including 6 people from the leadership team, as part of the \u201cfinal design walkthrough\u201d. Afterwards, everyone provided good, relevant feedback, yet it was unclear whose voice everyone should listen to. No one could answer who was making the decisions.<\/p>\n

It was clear that nobody knew their role in the meeting or in the project, so they all felt like they should contribute. Without knowing who makes decisions or who should give their input, everyone assumes they should be contributing \u2013 not giving your opinion leads to anxiety that the right decision might not be made, plus you don\u2019t know what level of detail to engage in.<\/p>\n

The first thing we did was agree on who was responsible for making final program decisions \u2013 Emmet<\/a> and Dashe, respectively design and engineering directors. This freed up four members of our leadership team from having to engage in the details \u2013 they could trust that Emmet and Dashe were on it. Others became contributors, like our lead designer Shek<\/a> and content strategist Elizabeth<\/a>. We also had a long list of team members that were kept abreast of decisions, like those in our growth and go to market teams.<\/p>\n

We applied the Driver, Approver, Contributor, Informed (DACI) model for decision-making.<\/p>\n