On the Fora team, Engineering, Product, and Design (EPD) operate in close partnership to develop consumer products. Why is this worth mentioning? While product development at most tech companies involves all three functions, most teams still follow the model where the PM is the product CEO, rather than one in which engineers, PMs, and designers collaborate as equal partners.

Fora has followed this more typical, top-down product development process where leadership dictated product strategy down the org ladder: PMs created year-long roadmaps with thoroughly-written Jira tickets, and designers and engineers implemented them. This approach frustrated high-performing designers and engineers, who cared deeply about knowing the why but did not have the answers because they were not even in the room when decisions were made. That lack of understanding and quiet dissatisfaction impeded a sense of ownership and produced uninspired outcomes.

Our current product development model relies on an equal partnership among Engineering, Product, and Design — necessary because our work is rapid and iterative. Most projects are staffed with Eng, PM, and Design leads from the start, especially when involving early-stage product or feature development. They begin with high-level direction from leadership and an initial "How Might We" question to frame the challenge and opportunity (aka significant hand-waving that the team then has to make sense of).

But it works because of this partnership. Instead of the responsibility and pressure resting solely on the PM to figure out the answer, all three leads work together to understand the problem, frame the opportunity, and chart a path forward.

No single function dominates — responsibilities, successes, and failures are shared. Engineers, PMs, and designers dive into the quantitative data, proactively tracking, interpreting, and applying it to product decisions. User research and validating designs are not just the domain of designers – everyone attends sessions and asks questions. And everyone contributes to tickets because each person holds a piece of the strategy and vision.

So how do we make decisions? Rather than deciding by consensus, which is slow, each lead is responsible for a different question:

1. Product: What we build

2. Design: How it's supposed to work

3. Engineering: How it's built

This doesn't fully capture the push-and-pull nature inherent in our process, which involves discovery, debate, and negotiation (the fun parts) undergirded by a shared understanding and commitment to strategy and vision. Interested in learning more? If knowing the impact of your work and having a shared voice in product development sounds invigorating, we'd love to chat.