Shipping product is quick and easy when you’re in a small startup, but what happens when you have a massive team with too many cooks in the kitchen or if there’s one too many delays with product launches? Can your company handle such a situation?
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.
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’s success or failure, whether you can deliver on your company goals or not.
Startups get complex
My colleague Mark previously wrote about how focus leads to silos 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.
Our principles of scoping small, shipping frequently and executing to six-week shipping cycles breaks down during these times, as we discovered when launching a brand new product, Articles. With more than 45 people across multiple teams and two continents needing to work together in lock step – this suddenly involves more than just shipping good product, quickly.
How do we retain our culture and fluid ways of working while avoiding chaos?
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.
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.?
What we learned
Launching Articles was the first time we trialled program management – 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.
We’d seen this problem before – 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.
Clear responsibilities
During my first week, I spent more than an hour with 16 people, including 6 people from the leadership team, as part of the “final design walkthrough”. 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.
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 – not giving your opinion leads to anxiety that the right decision might not be made, plus you don’t know what level of detail to engage in.
The first thing we did was agree on who was responsible for making final program decisions – Emmet and Dashe, respectively design and engineering directors. This freed up four members of our leadership team from having to engage in the details – they could trust that Emmet and Dashe were on it. Others became contributors, like our lead designer Shek and content strategist Elizabeth. 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.
We applied the Driver, Approver, Contributor, Informed (DACI) model for decision-making.
A Driver handles the overall coordination of the project, communication, identifying roles and responsibilities, etc. Usually this is the program manager or product manager.
Approvers make the decisions, and are ideally someone with authority to do so. They’re usually part of our leadership team.
Contributors have knowledge or expertise that may influence the decision, such as a product designer.
An Informed is someone notified of a decision or change once it is made. Usually this is someone from cross-functional teams who are impacted by that change, such as our growth team.
DACI was immensely impactful on Articles and also with subsequent programs. It enables progress, ensures the right decisions are made by the right people with the right input and that all relevant people are kept in the loop on changes and decisions, which happen regularly in product development.
This model is being used outside of program management too. We have product designers who collaborate to move designs forward. Our growth designers focus on the new-user experience of a feature – how will they discover it and know what it is? So they obviously need input from the person who designed the feature, but who makes the final decision? Agreeing on responsibilities upfront saves time and accelerates decision-making, while minimizing friction and frustration across teams.
Milestones
Like most startups, we don’t spend a lot of time planning – detailed estimates are expensive. But for a big launch with lots of stakeholders you need some sort of a plan. Why?
To get shit done.
To get a tangible sense of progress.
To communicate where you’re at to the cross-functional teams who need to input along the way.
Milestones are a powerful, but lightweight way of planning, without detailed spreadsheets and Gantt charts. A milestone represents a major progress point such as a deliverable or completion of a build that unblocks another team, or a point of other significance. Here’s the milestones we defined for Articles:
The best example from Articles was a milestone called “Marketing assets ready.” At this point, it meant the product was at a stage where the marketing team could start creating their assets, i.e. built and polished with no more front end changes. The mere existence of this milestone meant the Go-to-Market team could plan towards a launch date in the next two weeks. This had never happened before. Previously, such as with our Messenger launch, there were product changes right up to launch day, which put our marketing team in the difficult position of trying to make videos and marketing assets from an ever-changing product.
These types of defined milestones provide us with a common language and are a great tool for communicating and setting expectations. They also help when deciding what final polish to add and bugs to fix by asking the question, “Will this push out our Marketing assets milestone?”.
Keeping people informed
One of our biggest problems is internal communication and lack of visibility into what the teams are working on. This is largely left to the product managers, which works well when shipping small changes frequently, but when you’re shipping a major release there are more people to coordinate and to keep informed.
Here are some of the individuals we had to notify:
Leaders who wanted to know how we’re progressing towards company goals
Our sales team, who wanted to know when they could talk to customers about the new product
Marketing, who wanted to know when they could start crafting their story
Product Education, who wanted to know when they could make videos and write support docs.
Growth teams, who wanted to know when they could create the set up guide for new users.
The list goes on…
It can be difficult to keep everyone up to date on where things are at, to provide the right level of detail to the right group of people, using the right forum, and getting the frequency of communication right. Nailing this is key to successful program management.
Email: The security of receiving an email every week or two is reassuring. Even if you don’t have time to read the details, it should be easily scannable and you know somebody is managing it. Make sure only relevant people are included and you’re not spamming coworkers.
Slack: Slack is useful for regular and detailed updates. People can choose to join or leave channels based on how relevant it is to their current work, but the updates can get lost in the noise, especially if your teams are spread across timezones.
Dashboards: These are great for surfacing detailed plans or if you have many workstreams feeding into a program — I just use Excel currently. Having a dashboard enables team members to proactively get an update, assuming it’s always kept up-to-date. ?
Keeping everyone updated with the right amount of info in the proper forum is key.
We recently repackaged some of our features. This was a huge effort lead by our growth team with significant input from product teams, leaders, and marketing folks across the company. Throughout this program, I sent weekly email updates to stakeholders on the high-level status, milestone updates, and summary of key activities from each project stream. It was also an opportunity to call out any risks or issues we encountered during the week. These emails invariably got a huge response with positive comments — these updates were so valuable. Some people depended on them to plan and do their work, such as our product education team, but they also kept others out of the weeds enough to let the teams get on with their work (I’m talking about you, leadership team ?).
Mitigating and managing risk
An essential skill in program management is being proactive, always asking “what could go wrong?” While negative, it’s actually the most interesting part – and the most invisible. If you’re doing your job really well things just run smoothly — you’ve proactively uncovered the known risks and prevented or mitigated them, and you’ve managed the inevitable unexpected surprises to ensure minimal impact to the program’s delivery.
Risks can be also be technical, like how we maintained two production codebases for an extended beta period before launching our re-packaged app. But the trickiest ones to manage are people-related, for example, not knowing when pending paternity leave of a key team member will start, or trying to ensure your key engineer with all the technical knowledge in his head doesn’t get sick or hit by a bus on the way to work. There’s only so much mitigation that can be done with a daily vitamin to keep your team healthy. 🙂
There are different ways to uncover risks, but mostly you just need to ask a lot of questions: Why? What happens if that doesn’t work? What if somebody gets sick? What’s the worst thing that could possibly go wrong? Building relationships and trust with team members is often the best way of understanding risks, chatting about the program in a casual setting (over coffee) is generally where you really find out what really keeps people awake at night!
When will you need program management?
While shipping continues to be our heartbeat and we constantly think big and start small, we’ve realised that program management plays a critical role in delivering strategic goals, despite us being initially hesitant to introduce it.
You’ll know you need it when:
You keep missing your “launch date”.
You’re trying to deliver a complex product with multiple project tracks and many teams feeding into it.
Your teams aren’t working in sync and nobody really knows where a project is at any given time, including your leaders.
You have to deliver something big in a certain time frame due to marketing reasons, investor demands, market opportunity, etc.
There are different ways of defining your program management methodology and we realize that compared to some, ours is pretty lightweight. We’ve learned the key is getting the Goldilocks solution that fits your company and your culture: too much governance can become slow and cumbersome; not enough and you’re not solving the problem. We’ve done this by taking aspects of different methodologies, tweaking and adapting them to fit our culture and ways of working, and will continue to evolve it as we scale and face inevitable new challenges.
Comments