Being a Stand-in Product Manager

Hello there,

In case you missed it, I wrote about influencing the product roadmap (for paying subscribers only) and HEY strategies that deserve more attention from product and marketing people than the App Store "stunt".

A quick word about the latter: Many times, we focus on the output when we should focus on the input. We can control the input but often not the output. In the case of HEY, the App Store controversy definitely brought much more attention to the product launch. Getting press by arguing with Apple, however, is not something most startups could plan for. Neither is it useful for us to learn from. What's more useful is to learn about the things that we have control, such as having the founder do a demo, planning for early access, and giving away limited invite codes.

Today's note is about something I'm doing right now.

Being the decision-maker for a product team

The Analyze product manager (PM) is on a 2.5-week vacation, and he kindly asked me to be the decision-maker for the team on his behalf. This technically doesn't make me a PM but it's close.

For context, the Analyze team has one product manager, one product designer, one product marketer (me!), one engineering manager (EM), and four product engineers. We work in three-week product cycles. Usually, the PM and EM come together to plan the upcoming product cycles. The PM is out at the moment, and the EM is taking a vacation when the PM is back. So I'm helping to plan two product cycles to make sure things are smooth when the usual decision-makers are out.

We already have a few projects in the works, so I don't need or get to make big strategic decisions. But because I feel accountable to the team and I want to ensure things go well (in other words, I don't want to screw up), I thought a lot about product work recently. (I share some of my favorite product resources at the end.)

Here are the three big concepts I'm thinking about as I approach planning product work:

1. Capacity work

The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt introduced me to the theory of constraints. Businesses are usually limited by one or a handful of constraints that are preventing them from achieving their goals, which for most is to make a profit. In the book, the constraint is two machines in the manufacturing plant, which were the bottlenecks. By increasing the capacity of the two machines, the plant could ship customer orders faster.

In tech startups, the constraint is often the engineering team. This isn't meant to be a negative thing about engineers. In fact, engineers are, to me, the most valuable asset in tech startups. Engineers are often the limiting factor because programming tends to take more time than design and marketing.

The more we can help engineers ship faster, the better the product gets and the more profitable the startup becomes.

An example from our team right now is improving our staging environment, where we test new code before shipping them. Often times, the staging environment and the production environment (i.e. the app that customers are using) are not aligned. So even if something is working in the staging environment, it could be broken when pushed to production. This creates bugs and a poor experience for customers even though the staging environment is meant to catch these bugs. An improved staging environment will allow engineers to more easily test their code and the PM to do quality assurance (QA). This reduces testing and QA time, which reduces shipping time.

I call this type of work capacity work.

Capacity work is not visible work that will show up in the product, so sometimes it's hard to prioritize them. People who do capacity work also rarely get recognition. But it is something that will make engineers be more productive and ship faster in the future. Therefore, I think it should be prioritized—and celebrated.

2. Bounces between "departments"

The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Winby Gene Kim, Kevin Behr, and George Spafford, built on top of The Goal and showed how the theory of constraints can also be applied to IT organizations. The main takeaway I had is the importance of reducing bounces between departments.

In a manufacturing plant, raw materials systematically go through several machines to be processed before being assembled. Whenever the materials need to be re-processed by a machine (i.e. go to the previous step), time is wasted. In IT organizations and tech startups, that "backflow" is less visible but definitely present. When a product spec is not comprehensive, the designer will have to repeatedly ask the PM for clarification. When the design spec is not comprehensive, the engineers will have to repeatedly ask the designer for clarification.

When the work gets "bounced" between the PM, designer, and engineers, time is wasted.

To make things worse, more time is lost because of the waiting time. Rarely does anyone respond immediately so the other party can only wait. This increases the overall shipping time.

Such bounces are more dangerous in tech startups than manufacturing plants because it's less visible. In a plant, you can see the materials physically move back to the previous machine. In tech startups, bounces are disguised as Slack messages, Jira comments, and so on.

I think it's rare for any startups to totally eliminate such bounces because the product spec would often need design inputs and the design spec would need engineering inputs. But any reduction in bouncing can help reduce the overall shipping time. At Buffer, we are using discovery briefs and design briefs to provide more clarity and to reduce bouncing. We are still making a lot of bounces, so we are finding ways to refine the briefs and our processes.

3. A product is like a tree

I once gave the analogy that building a product is like growing a tree. Without a solid trunk, the branches and leaves will not thrive. And you also don't want a tree with a solid trunk but no branches or leaves.

A product manager has to balance the ratio of trunk work and branch-and-leaf work.

The core functionalities of a product are like the trunk of a tree. For a social media analytics product like Analyze, the "trunk" is data reliability, report creation, and performance tracking. Removing any of these will kill the product.

The secondary functionalities are like the branches of a tree, and the nice-to-have delights are like the leaves. For Analyze, the "branches" are things such as being able to slice and dice the data in different ways and the "leaves" are stuff like the colors of the graphs.

In each three-week product cycle, we tend to work on one big project and a few small tasks. This means we have to be careful in prioritizing what to work on. While branch-and-leaf work is usually smaller in scope, easier to do, and more fun to work on, I believe the majority of the time should be spent on trunk work. This isn't to say trunk work would always be huge in scope. They would feel large compared with leaf work (report creation vs colors of graphs) but they should be broken down into smaller pieces when possible. For example, report creation can be broken down into report annotations, PDF export, scheduled reporting, report sharing, and so on.

Balancing between trunk work and branch-and-leaf work is more of an art than science. I don't think there's a blanket guideline that covers all situations.

Product resources

All these thinking around product planning has gotten me even more interested in product management. I'd love to learn more about product management.

Would you mind sharing one of your favorite resources?

Here are a few of mine: