From Trello to The Knot: Roles, Velocity and the Question "What Are You Optimizing For?"

Miller is senior vice president and head of product at The Knot Worldwide, whose brands such as The Bump cover big life celebrations beyond weddings. She says the company is sticking to celebrations, not the sad milestones Lenny jokingly suggests. Before that she ran growth and retention at Trello for over five years.

She explains that Trello began as a simple, tactile planning tool for anyone, so early users included small businesses, families and people planning weddings. Its "progressive disclosure" let users start small and grow into more sophisticated needs, whereas competitors often start complex. Her own work was about getting more teams, not just software teams, into the product, which meant many small enterprise features such as label colors, naming and inviting teams rather than individuals.

On choosing between tools, she says smaller teams still ideating are well served by Trello for collecting and prioritizing ideas and tracking discovery, while decided work that must be broken into assigned tasks suits Jira better, though she expects some to disagree. She also describes the bittersweet nature of productivity software, where a PM, designer, engineer and data scientist each measure productivity differently, so you cover the core 80 percent and accept that no one will be fully happy.

Miller sees a lot in common between engaged couples and PMs: both face high stakes and expectations, many stakeholders, multiple vendors and a long project horizon, which for a wedding is typically 12 to 18 months. The Knot spans planning tools, a two-sided marketplace, e-commerce for registry and paper, affiliate and ads businesses, so it differs from a SaaS productivity tool.

She finds couples more emotionally demanding to serve than PM customers, because for many this is the most meaningful time of their lives and most will not do it again. That emotional side is the same whether the wedding has hundreds of guests or ten close friends, and she does not want to let them down. Lenny teases that a baby-shower invitation and registry platform is an obvious next step, and she says they have thought about it.

Her one Trello tip is to use Power-Ups, the integrations, to make it more powerful than people expect.

Miller says building impactful teams starts with clearly identifying roles and responsibilities, and she champions a "quartet" of product, design, engineering and data rather than the classic triad. In her exercise, leaders write down what they expect from each counterpart, review those expectations together and arrive at a contract that is then cascaded through the org. It is time-intensive and prompts debate, but she thinks the early contract is vital.

There are templates covering expectations as an individual contributor, as a manager, and toward each other, including shared work. For example, a PM writes the product brief, the data scientist helps write the experiment brief, and both own analysis together. Each person writes their own role and their expectations of others, and then they review it jointly.

She notes a recent shift: with Scrum Masters largely gone, project management has moved from PMs toward engineering managers, who are increasingly expected to ensure sprint goals are met. Because the PM role is so ill-defined, people tend to put too much on the PM's plate, and the exercise shows that no one human can do it all. The triad recognizes shared responsibility, so the PM leads on making sure everyone understands what and why, but designers, engineering managers and data scientists evangelize it too.

Miller wants data scientists embedded in product teams, as Lenny saw at Airbnb, though she admits it is not everywhere. From her PM experience, access to data and someone to troubleshoot with was always a blocker, and negotiating for another team's resources made it worse. A dedicated data person also gets better by learning one product area in depth and spotting patterns, and whether they are called scientists or analysts depends on the team's needs.

When the roles framework is revisited, it is usually because something went off the rails, and she says the common cause is execution and velocity. For PMs this is often the velocity of decision-making: how long it takes to say a thing is needed, define it and decide whether to do it. For engineering, it is often about breaking tickets into small pieces, which the PM also shares responsibility for by articulating the goal clearly.

Miller says that in recent years the companies she has coached all talked about outcomes, which is right, but some, including herself at times, "swung way too far" and forgot that output is an indicator. A team can ideate well and write all the briefs, but if it does not ship enough to market quickly, the rest matters less. For her, outcomes are the goals and plans, such as OKRs, while the more tries a team gets, the likelier it is to get it right.

She believes product managers are the ones who must drive urgency, mostly by reminding people often, not by demanding lists of shipped work. Talking about the experimentation backlog and how quickly items get out, and keeping a pulse on competitors, helps. She has worked with founders who said they had no competition, only to see later that others were shipping great products. Lenny links this to Frank Slootman's advice in *Amp It Up* to never let off the gas on urgency.

For a heuristic on whether a team is moving fast enough, Miller looks at how much time goes to optimizations versus bigger bets and how long simple things take; a task that takes a week or two of work but resurfaces two quarters later is a warning sign. The split between big bets and optimizations, she says, depends on the age and stage of the business. When a team is slow, she asks simple questions: what did you deliver this sprint, what reached production and what was the cycle time.

Looking back since 2010, Miller says the biggest change is how mainstream product management has become, with degrees, business-school paths and a whole business around it. She thinks that may have removed some quirkiness and creativity. Roles are converging: PMs are expected to be a bit more technical, designers more business-oriented, and engineers more product- and user-focused, which she says brings teams closer to deep collaboration.

Asked whether PMs must code, she says it is not required, though more PMs take bootcamps and data classes, which helps. She herself has no technical background. Lenny notes that a LinkedIn search showed about 2 million people with a PM title, 800,000 of them in the US.

For breaking into the field there are many routes, including big-company programs, but she especially likes startups because the work is so problem-solving oriented. You may lack a teacher, but the product will teach you what is right and wrong if the team moves quickly, and you touch every function.

Miller says the PM role is hard: you are expected to be competent across many areas, have answers and stay calm. She reminds her PMs she understands this and encourages them to solve for one thing at a time. As a mother, she no longer uses the word balance but asks what she is optimizing for today, this quarter or this year, accepting that you cannot have everything at once.

Early in her career she worked nonstop around big releases, while still fitting in marathon training by starting work late after a long run. Today she may do all the school drop-offs in a given week. Lenny reads this as sprinting hard for a period and recharging after, and she adds that life stage matters: right now she probably would not join a very early startup that demands long in-person stretches.

Miller has worked with remote or distributed teams her whole career, including in Shanghai, Europe and Latin America. What works, she says, is documentation, asynchronous communication and strong written and video skills. But solving hard problems remotely with people you have never broken bread or disagreed with in person is much harder, so when a gnarly problem arises she calls a roughly 48-hour, two-night get-together with a tight agenda and dinners built in.

In one example, a strategy change required landing core decisions, and doc comments across time zones dragged on for days. The unlock at the in-person session was giving the data person space to educate everyone. Lenny notes that people often lack the same information, so aligning on shared foundations resolves a lot.

She credits Trello and Atlassian for setting standards: flexible schedules but overlapping online hours each day, and in-person onboarding for new hires for about a week, for culture and a contact to reach out to.

Having worked in China, the UK and the US, Miller finds confusion about what product management is universal, as are goal-setting approaches and the need for urgency. In Shanghai she felt the PM was expected to have all the answers, so she got her team to help her find them, which taught her to share the product management load. She also learned to make space for ideas from any function and from non-native English speakers.

She recommends working across cultures because empathy for the people and problems you serve is essential to the job, and being out of your comfort zone is one way to learn it. Her framework is a single question she asks colleagues, friends, her husband and her five-year-old: "What are you optimizing for?" It applies to OKRs and goal-setting, since if that is unclear then trade-offs will be too.