Trello’s Product Lead on the Unique Ramp to a 10-Person Product Org

Trello’s Product Lead on the Unique Ramp to a 10-Person Product Org

Trello's Nikita Miller has made a specialty of being the fourth product manager, leading teams through that unique transition from scrappy early-stage startup to a company that can scale. Here, she shares three strategies product leaders must implement to bridge that gap and get the most out of rapi

We hear a lot of talk about the first employee at a startup or on a team. Nikita Dyer Miller has made a specialty of being the fourth product manager.

It may not sound glamorous, but that’s a uniquely challenging — and impactful — space to occupy. She’s found that for a product team, the boom from a couple of PMs to 10 or more is a make-or-break moment. It marks a greater shift and line in the sand: the threshold between early stage and growth stage, old guard and new guard, original and restructured team. It’s a subtle shift in a company’s evolution that can feel dramatic in retrospect. Miller has spent her career in that transition, joining three successful companies as their fourth (and once third) PM.

At startups including Knewton and Pixable — and now as a product lead for Trello (acquired by Atlassian) — Miller has seen teams nearly triple in size in under two years. She knows what it takes to ride that wave and stay calm amid change and uncertainty. In fact, it’s all she’s ever known.

In this exclusive interview, Miller shares her well-honed insights into successfully leading a product team through that unique transition, from scrappy early-stage startup to a company with processes that can scale. She shares the three strategies product leaders must implement to successfully bridge that gap and come out thriving. And she offers advice for both grounding and getting the most out of a rapidly maturing team.


Early in her career, Miller adopted a practice to kick off each new role: she hits the ground running with a series of internal interviews. She seeks to figure out the future of the product by piecing together its history. Aside from the founders and CEO, she intentionally interviews members of the product development triad (engineering, product and design), particularly the head of product, engineers and engineering managers and designers.

“After doing those interviews, I look at all of my notes and try to identify trends in how product decisions have been made and whether there are principles that can be distilled from these experiences,” says Miller. “What are the things that everyone seemed to agree on? What are the things that seemed off? I quickly realized that the whole product team would benefit from those findings. So I formalized this process to articulate and codify my team’s values.”

“When I joined Trello, a lot of decisions had been made based on a set of principles that had never really been documented. And as the company was growing there wasn’t a shared recognition or understanding of these principles. There was no single source of truth that anyone could refer to,” says Miller. “So as a product group, we took the opportunity to document what we thought the principles were for how the product was developed and what made it stand out. It became clear that this necessarily had to be a cross-functional exercise.”

Newcomers have a natural opportunity to press pause and implement this kind of exercise. ‘But there are other inflection points when taking a step back to articulate principles — and get everyone on the same page — is particularly valuable,” says Miller. “Adding a major new product line, for example, like an enterprise offering for a company that had previously focused on consumer. Or attempting to significantly grow your user base.”

Interview when you’re new. Others are more willing to press pause for you then. It’s a unique moment to surface principles.

Periods of team growth, too, are important junctures to take stock of your principles. “Let's say you go from three to seven, or three to 10. Now you have teams that need to work with each other and potentially on features that cut across different groups. What does that look like?” Growth may demand a new delivery cadence, for example. “Do we need to start using new technology, or technologies?” says Miller, “And what does that mean for not only how we operate, but potentially our product principles?”

How to document product principles

When you conduct this exercise — whatever the inflection point — the process is the same:

  • Pick interview subjects on all rungs of the ladder. To start getting a sense of a product’s story, talk to the people who’ve been writing it. Miller recommends starting with 1:1 interviews to get people’s honest and unbiased takes. Speak to people who’ve been with the company for a while, and be sure to include both the highest-up, like the CEO, and the people who’ve been on the ground implementing projects. “I recommend not only speaking with members of design, engineering, product, but also with your sales and support teammates. They have unique contact with your customers and how they view and use your product.”
  • Conduct your interviews in two weeks. Keep this time frame fairly compact; it’s important to show some results from these efforts relatively quickly. Miller usually completes this step in two weeks, though the whole process of documenting product principles will likely take longer. Take notes as you go. “I’ve gotten great insights by centering my conversation around a few key questions: What's your least favorite part of the product — why and how do you think we got there? What part of the product are you most proud of? What feature/aspect of the product do you think customers are most excited about? Why do you think that is?” she says.
  • Look for recurring themes. As you go through all those sets of notes, commonalities will start to emerge in people’s comments. Pay attention and note patterns— those are likely to inform your initial list of principles.
  • Note outliers, too. You’ll also want to raise any noteworthy outliers with team. There’s no scientific process for distinguishing between offhand comments and real food for thought, so use your best judgment. If someone speaks passionately about a topic, that’s probably worth raising with the broader team — even if no one else brought it up.
  • Draft your dozen. At this point, the list will likely be much longer than the final version. Miller recommends aiming for 10-12 proposed principles, which you’ll likely pare down in conversation with the team.
  • Share with the product team. Explain the exercise to those who didn’t participate in interviews, then share the themes you uncovered. If you need more context to better define any entries on the list, get it now. Miller likes to share the draft prior to an in-person meeting to give teammates time to mull it over. “Folks are able to add comments, rearrange, edit and add themes before meeting,” she says. “The team lead’s role is to facilitate a debate with as little bias as possible. And leave plenty of time. These often-passionate discussions take multiple two to three hour sessions.”
  • Pare the list. Get your list down to the essentials. Each item on the draft list may be valuable, but is it the most valuable? “Toward the end it's a question of trade-offs,” says Miller. So ask the team to list their top five. “In my experience, the top five is usually fairly consistent. People might rank them differently, but that’s okay. At this point, each item on the list is essential, so don’t worry about prioritizing one over another.”
Product principles, like product features, will require trade-offs. You don’t want a product — or a product team — that isn’t forged by tough choices.

If you get stuck while you’re defining terms and making trade-offs as a group, try one of Miller’s favorite exercises: “Ask each person to make a list of the 10 attributes that define your product. Review them together and group attributes based on similarities. For the ones that are similar ask a person to define it,” says Miller. “Ask others in the group if they agree, disagree, would amend and why. This helps generate a nuanced understanding of the concepts behind your product principles.”

By the end of this process, you should arrive at an agreed-upon list of top principles and clearly defined terms that you can share more broadly and solicit feedback from other teams. And indeed, defining terms is one of the great benefits of this exercise. “Take the time to get these definitions right because ultimately they will become the standard by which the product development teams decisions are measured,” says Miller.

The last step in the process is to publish the final list internally, particularly to the entire triad (product, design, engineering) — which is most directly affected by product principles — and to the leadership team. By then, you should have enough input from across the company to get everyone’s buy-in. “I don’t believe in simply publishing product principles by email. Instead, present at a company all hands or town hall where you can give context, acknowledge the individuals who participated and teams that have collaborated to make the list possible. This makes it a conversation and allows you to field questions,” she says. “You might also find that once product kicks off this process, other teams follow suit, refining terms in a way that best speaks to their own discipline. In Trello’s case, while Product started this process, Design completed it. In the end, we arrived at a set of principles that resonates with the entire company. That type of proliferation leads to adoption and subscription to a shared source of truth. That’s a good sign that you’ve hit on the principles for those who touch the product.”

Finally, once you’ve documented your list of principles, use them! “If you’re making a business case for a feature, designing the user experience, implementing the functionality, or testing the feature, the product principles give you a framework to evaluate what you’re working on,” says Miller. “Don’t work so hard to develop them and forget to use them. Reference them daily.”


In other words: as you scale from single to double-digit product team, find and hire specialists who can go deep in their area of expertise. Over 10 years and four companies, there are a couple of things Miller has noticed about product groups on the brink of growing past their early team: They’re typically comprised of get-the-job-done generalists, and they tend not to subscribe to a whole lot of process.

When I walk into companies on the cusp of major growth, I generally see a lot of smart, talented product people who can get shit done in just about any area, but lack deep expertise.

In a rapidly growing company, specific expertise becomes essential — and quickly needed. When it comes to process, small, early teams don’t need much. “As a company grows, it becomes more difficult to collaborate across teams,” says Miller. “Without clear and consistent processes, teams are unlikely to work their way toward the best solutions.”

As your product org grows from a couple of people into the double digits, consider these three factors to make the right hiring decisions and build a well-rounded team:

1. Skills

“As a team grows and a product grows, you usually need people who can specialize in certain areas,” says Miller. For example, while all PMs should have some degree of analytics skills, many teams find that they hit a point where they need to add a data PM. “That is a very specific set of skills that goes beyond just being proficient or competent in analytics.”

If your two- or three-person team is on the brink of doubling or tripling, start by taking stock of which skill sets and interests your existing PMs demonstrate. “If you had to define where they spiked, in terms of PM capabilities or interests, where is that?” says Miller. “Then consider your near- to medium-term goals, and your upcoming projects. Which skills do you need to be sure you have on board?"

“If you’re focused on revenue at this point in the product, for example, a product manager with strong experience in monetization and business analysis is vital,” she says. “In many cases, it's really important to have a PM on the user research or user empathy side, someone that really spikes in understanding end-user needs and experimentation around that.”

Hiring for diverse skill sets not only empowers your team tactically, but also deepens your ability to develop and mentor each product manager. “Hiring individuals that are competent across all product skills but excel in specific areas is a way to uplift the entire team. Eventually, PMs will educate each other in their specialties,” says Miller.

2. Approach

Beyond skill sets, you also need to consider the approach of each PM, whether prospective or already hired. That is, find where each person falls on one particularly important axis: visionary vs. tactical. Each approach is valuable, but you need to make sure that you achieve a balance.

What is the difference between the two? "Let’s say your startup is focusing on revamping a product’s mobile experience. A more visionary PM would say, ‘Okay, this is where I see mobile products going in the next two to three years, and these are all the trends we need to consider,’” says Miller. “Whereas someone that's more focused on execution will say, ‘Okay, if that’s where you want to be, here are the nine milestones I think we need to hit in order to get there.’”

In this particular growth stage — as a company’s product team scales from two to 10 — evaluate the competencies of your product team and the strengths of the leadership team. “If the leadership team has strong visionaries — and small startups tend to — then it’s important to bolster their vision with PMs who skew towards product strategy and execution,” says Miller. “If the founders have moved on and aren’t as actively leading the product, then the vision will have to be generated within your product team.”

Understanding where each PM on your team falls on the visionary-tactical axis will also help you manage them most effectively. Sometimes, that means fostering simple peer-to-peer collaboration. “I try to do this during our product meetings, when I think individuals have been great in one area or the other,” says Miller. “So, if I'm talking to one of our PMs that is on the visionary side, I say, ‘This is amazing, and sounds really interesting. I think it would be great for you to chat with person X,’ who may be stronger on execution."

But a great product lead will also need to spend a significant chunk of their own time on coaching. And stretching a visionary PM to think tactically, and vice versa, is a common theme of that coaching. “Great PMs are able to switch between the two, visionary and tactical. There are also ways you can encourage people to think whichever way comes less naturally. Quarterly planning, for example, can be a great way to get a visionary type to think more tactically. If you're responsible for a three-month roadmap with milestones, you necessarily have to start thinking in a more execution-oriented way,” says Miller. “I’ve once worked with a PM on a desktop product. As a visionary, he had difficulty answering the question ‘What can we work on over the next few months to make the most progress?’ Ultimately, we worked on a series of fairly small exercises having to do with auditing the existing desktop client, using customer feedback to identify low hanging fruit, and prioritizing larger projects based on potential impact on our key results. These defined projects and moved the horizon closer to the present for him.”

3. Seniority

A growing team will inevitably include a mix of senior and junior members. The most obvious difference, of course, is experience, and whether people have managed a product before or have familiarity with a variety of contexts.

But Miller has identified a subtler distinction between the two, particularly in the startup realm, and that’s a PM’s ability to navigate change. “Folks who won’t be paralyzed by large changes within a company are great resources. They know how to behave in that environment. We've recently hired a few more experienced people. It’s not their first rodeo,” she says. “A lot of things change, and they don't lose their cool. That makes a big difference on a growing team.”


As companies and their product teams mature from early stage to growth stage, the realities of their new size manifest particularly clearly in how information is shared. “I find that in early product teams, or early companies, everyone tends to consume all of the information, all of the time,” says Miller. “As teams grow, though, each person has to specialize more and focus on their particular responsibilities. Capturing people’s attention — and distinguishing essential information from noise — becomes harder.”

Miller’s fix is to draft executive summaries for key communications — that is, brief summaries of the underlying facts and data, designed to quickly convey high-level takeaways (while sparing readers reams of research). Take the product feature brief, which is a one-sheet her team drafts before they begin spec-ing a new feature. “Someone looking at this feature brief can say, ‘Okay, I understand the vision. I get the preliminary business case. I know what the core set of requirements are. I know how we are going to measure it,’” she says.

Keeping things concise is essential; stick to one page. “Bad executive summaries attempt to ‘show all your work.’ The goal is to convey to leadership the decision you recommend, and the key facts that lead you to that conclusion. You don’t want to leave any room for misinterpretation or skimming,” says Miller. “A good exec summary is a way to say, ‘This is a situation that we're going through as a team. There's a complication — or a question of trade-offs — and here's our proposed answer.’”

Bad exec summaries attempt to show all your work. Good ones show how you understand all parts of the problem.

Miller saw the benefits of this straightforward communication particularly clearly recently, when her team had to make a tough call: launch a new product on time with a known flaw, or significantly delay the ship date to fix it at the risk of losing short term revenue. The product team turned to executive summaries to help clearly communicate the trade-off.

“The brief summarized the situation, the snag, the time frame that it would push this project out and the potential cost,” says Miller. “The question was, ‘What do we do given the above?’ And our proposed answer was, ‘We should forgo that early revenue to avoid possible churn, take the extra time and delay the release. We presented this answer and then clearly laid out the evidence and reasoning in support for this solution.’"

With as many as ten people involved in making this call, Miller needed a way to get everyone up to speed, as quickly as possible, without getting bogged down in every detail. She worked with the PM leading the product to draft the document, and then distributed it to all the involved people: CEO, chief of staff, the entire product team, and more.

Ultimately, that brief had an even bigger impact than Miller had anticipated. “Our CEO actually had a different answer in mind, but after reading it, he went back and said, ‘Okay, I didn't think of it in this way.’ He agreed with the PM’s recommendation, and launch was delayed,” says Miller. “I spoke to him about it later, and he said, ‘Well this was the first time I had actually seen all these inputs consolidated.’"

The Minto Pyramid Principle

While Miller has written this type of brief for years, she recently learned about a framework that has only made them more effective. “Michael Dearing introduced me to the Minto Pyramid Principle earlier this year,” she says. “It’s been a useful framework for me to use both with leadership and with our teams.”

The pyramid, developed by former consultant Barbara Minto, offers a template for any business communication that aims to present a person’s or team’s thinking on a key issue. At its core is the notion that any persuasive argument should proceed from a single clear conclusion — the tip of the pyramid — supported by logically ordered ideas and arguments. To shape your thinking in this way, Minto recommends focusing on four key elements: the situation, the complication, the question that needs to be resolved, and your answer.

“It's been used in consulting for years,” says Miller. “It's very well known, but it also tends to have a very corporate, business school tone. And in the startup world, that can be a liability."

So while she recommends that leaders embrace the meat of the Pyramid Principle, Miller also encourages them to use the language and style that best suits their culture. “Even changing the headers can have a big impact. So instead of ‘situation’ use ‘Here’s what’s going on.’ Instead of complication, it’s ‘This is why it’s an issue.’ Then it’s ‘This is what we need to solve,’ and ‘Here’s what I propose,’” she says. “In some companies, that goes a long way. It tones down what might otherwise come off as being too formal, but gets you to the same place.”

Successfully wielding this tool, in Miller’s experience, also boils down to knowing your team and what will work best for them. She has found, for example, that some teams want as much information as you have — and might be uneasy with seeing only a cheat sheet.

“That's the only time I have seen it fail is when the PM underestimates just how much information the team wants to know,” says Miller. “That doesn’t mean ditching the executive summary, though. That tool is vital for achieving consensus and aligning different parts of your organization. Instead, you might need to supplement the summary with an appendix of sorts. Create the one-page summary, and then have a ‘Here's everything else if you need it’ section.”


Internalize the three strategies that Miller has seen have the highest impact on a rapidly maturing product team: 1) interview for and document product principles, 2) hire your first specialists to complement PM generalists, and 3) introduce and elevate executive summaries.

But there’s one other factor that can’t be overstated: as teams stretch from two to 10 people, they also need a certain kind of leader. If the product lead has been with a startup from the get-go, the team’s evolution demands personal growth, too. “One of the things that's most difficult as a product team grows is that you can’t be as close to the product itself. Figuring out how to navigate that is actually tricky,” says Miller. “The challenge for the leader of a midsize product team — no longer the scrappy team of two or three, but not yet the well-oiled machine of an established company — is doubly tricky.”

They need to play both sides, staying involved enough to understand what’s going on with the product while still giving PMs the space to manage their piece of the big picture. “Take our decision to delay launch of the enterprise product. The PM that I managed was the best person to write that brief because she was closest to the problem and the solution. And I had to back off a little bit. I needed to say, ‘Here’s the framework. I can help you through it.’ But the details and implementation of that brief were all her,” says Miller. “And for me, being able to let go of that was challenging.”

A successful product lead at this stage needs to be comfortable moving between details and high-level planning, between executing tasks and delegating. And that’s just one case when flexibility is key. Because change is the norm at startups of this size, and leaders need to be ready and willing to provide stability amid that uncertainty. “This stage of a startup’s growth is often rife with uncertainty; things are evolving, and the new direction isn’t always well-articulated. Leaders, then, need to fill one particularly valuable role outside of their functional responsibilities: they need to give their teams anchors when everything around them seems to be in flux,” says Miller. “The principles, key hires and executive summaries serve as anchors. Because things inevitably drift, shift and fall apart. Sidestepping that is futile. Use your energy to tether to frameworks that you can work with until you figure it all out.”

Illustration by Alejandro Garcia Ibanez featuring Nikita Miller.