Brian Tolkin on Hiring Product Teams and Finding the Problem That Matters

Opendoor head of product Brian Tolkin talks with Harry Stebbings about product management, hiring and AI. His examples draw on his work at Opendoor and earlier experience at Uber, so his views of those companies reflect his professional involvement.

Tolkin recalls launching Uber Pool in China while a local data center was being set up. The team worked through technical problems overnight before a morning launch, an experience that showed him how much a product depends on infrastructure beneath the interface.

For shared rides, good matches depend on mapping and routing data as well as rider supply. Tolkin says the team underestimated the difficulty of matching riders against complex road infrastructure when its underlying local data was weaker than it needed.

He also wishes the team had better appreciated differences in local design conventions. He sees some convergence in international app design, but treats that as an observation rather than a fixed rule for every market.

His worst Uber product decision was making Uber Pool the default in a way that could override a rider’s earlier choice of UberX. Some people accidentally selected a shared ride and were surprised when another passenger appeared.

Tolkin says the decision prioritized the company’s need to test marketplace liquidity over respect for user choice. Product managers must consider both business and customer needs, and he believes the team leaned too far in one direction.

AI may change the tools a product manager uses: a working prototype may replace a written document earlier in the process. Tolkin expects product, design and engineering work to converge, but says the core job remains understanding users and finding a solution that also works for the business.

More accessible prototypes can improve research by letting customers react to something concrete. He does not predict that a particular design company will disappear; his broader expectation is that more product managers will begin with prototypes.

Traditional development often moves from a product document to a design file and then to engineering. Tolkin expects AI to compress parts of this sequence and enable product managers and designers to collaborate on a prototype before writing extensive specifications.

A good early one-pager should explain the problem and the insight behind it. Tolkin says the solution can still be underexplored; a common mistake is filling the document with a proposed solution before the team agrees on the problem.

For prioritization he considers impact, confidence and effort, but also the company’s time horizon. New features, experience improvements and technical debt compete for resources, and taking on debt now means accepting a cost later.

For an early-stage company still proving demand and trying to grow, Tolkin would often favor earning the right to survive before slowing down to repay all technical debt. He notes that the answer depends on the competitive situation and the severity of the problem.

He thinks a CEO should usually own product direction in the earliest stages, though not necessarily forever. As a company grows, responsibilities can change; outsourcing the core product too early can make founder judgment harder to apply.

Moving from one product to several creates product and cultural challenges. A new initiative should have enough space to experiment without degrading the existing experience before the new offering has proved itself.

Tolkin says a second product need not directly improve the first, but should use some existing company advantage or serve an existing customer set. A new customer, a new capability and no shared advantage may amount to building a separate company.

He views the Uber Pool default as an example of a second product harming the core experience. At Opendoor, he says the team learned to focus more clearly on its strengths and the ways it can help existing sellers, a description informed by his current role.

A product manager hears requests from executives, users, sales, support and data. Tolkin calls the central skill simplification: find the underlying problem in that noise rather than treat every requested feature as equally important.

For Uber, he reduces the core experience to a car being available quickly at a reasonable price. Other issues still matter, but this framing helps the team connect priorities to the outcomes that users value.

Leaders must make the company’s primary objective clear so teams can understand how their own work contributes. Tolkin also notes that different people may fit different stages of a company as the work and organizational needs change.

Stebbings asks whether speed or product taste matters more. Tolkin discusses the value of moving quickly while making decisions informed by evidence and judgment, rather than assuming a single style fits every problem.

He puts himself somewhat toward the data-driven end of a spectrum, while emphasizing that customer conversations are data too. Qualitative evidence from users is different from an experiment, but it can still be valuable in a decision.

Simplicity means removing unnecessary complexity, not eliminating every option. Uber’s choice of vehicle types makes the interface more complex than a single button, but can still be a simple way to serve different needs.

Tolkin rejects both endless consensus-seeking and a leader who refuses to hear other views. Gather the relevant expertise, make a timely decision and explain the direction; slow decisions and ignoring information can both be costly.

For hiring, he distinguishes a good individual product manager from a good fit for a particular team. A technical infrastructure problem, a design-heavy experience and a business operations challenge may each call for different strengths.

He says “you hire your strategy”: the person chosen will influence how success is defined and what the team prioritizes. Hiring should consider both the needs of the specific product team and gaps in the broader product organization.

When a hire fails, Tolkin says the company or hiring manager should examine its own role. The person may not have had clear goals, may have had the wrong skills for the problem, or may have faced more ambiguity than they could resolve.

He values evidence of real work: prior collaboration, an example of past work or a consistent case study with an appropriately ambiguous problem. The point is to assess clarity of thought and problem-solving, not merely whether a candidate knows a particular sprint ritual.

For a sprint, Tolkin’s practical advice is to make the intended outcome clear to everyone. He suggests two weeks for many teams and says some growth teams can work in one-week cycles, depending on their needs.

By alignment he means that each person understands the most important work, why it matters and how it connects to customer or company goals. It does not require everyone to agree on every decision.

He supports disagreeing and committing for a period when a decision has been made. If someone repeatedly disagrees with the fundamental direction for too long, he says, they may need to reconsider whether the role is a good fit.

Tolkin sees internal transfers into product management as undervalued because colleagues can bring both functional expertise and company context. On AI, he and Stebbings debate which skills will become more important; their assessments are predictions, not measured future labor outcomes.

At Opendoor, he describes product, operations and design as closely linked because a digital experience has a physical-world counterpart. A smooth interface can still be undermined by what happens in a home transaction, so teams must account for operational reality.

A product leader may deliberately choose a quick, useful shipment to rebuild momentum after a difficult period. Tolkin says confidence and progress can compound, even if that means temporarily prioritizing a smaller project over a more ambitious one.

Having spent long periods at two companies, he believes people often become more effective as they build relationships and context. He acknowledges his own bias and says people should leave when a role is genuinely the wrong fit.

In quick-fire advice, Tolkin suggests an early-stage company can be a useful place for a new graduate to see some established practices while still making their own mistakes. For parents, he recommends accepting help from family and friends.

He says founders often miss product-market fit because they fall in love with a solution without deeply understanding the problem. His favorite Uber product decision was upfront pricing, which let riders see the cost before requesting a shared ride.

He identifies operations as a function that can have tension with product because its pace and methods differ. In businesses that involve physical services, the teams need a shared language for problems that may have either a technical or an operational solution.

Tolkin closes by saying that breaking down silos between product, design and engineering with AI will be harder than many assume. He hopes more teams can move rapidly from an idea to a testable prototype while retaining clear judgment about the problem.