Sam Broner

Sam Broner

Software in Seattle, Boston & NYC

Engineering is Control. Product is Coordination. Venture is Ambiguity.

Career, Personal, Tech

Friends sometimes ask for my perspective when considering a role in engineering, product, or venture. I needed time in each before I could summarize the differences in culture and objective.

In my view, the differences are broadly defined by control, coordination, and timeline.

Engineering: Control, Iteration, and Coordination

As an engineer, it’s easy to fall in love with the control you have over the product and the satisfaction of quickly improving it. I loved to build fast, but would also build to make a point. “I think it’d be better this way and I’ll prove it to you.” Building to prove a point can create coordination issues (I’ve grown and I’m sorry), but on the happy path you work late to make sure great features are included in tomorrow’s build.

There’s a lot of good that comes from proximity and speed: (software) engineering solutions only need to be good enough and if you ship fast, you learn fast. Engineers are as close to the product as possible and many have good product sensibilities. Regardless, you can almost always go back and fix things incrementally or replace them, so there’s no need to be a perfectionist when most systems will be iterative anyway.

But things change once you start making larger architectural and multi-team decisions. It takes a unique (almost imaginary?) engineer to quickly and individually deliver complex projects that touch many teams and features. Instead, great architects encourage engineering practices that make complex changes simpler to coordinate and then design effective solutions that minimize unforeseen costs.

Even with a good plan, the "will to coordinate" needs to be continuously coaxed and it's more effective to build momentum by sharing credit for the solution. Momentum becomes a valuable commodity and, when pointed in the wrong direction, a risk.

Product: Managing the Vision

The best product owners have an insight that leads to a grand vision, but then hold that vision gently so they can find a viable path to expressing it. At the same time, product managers own the product’s details - crafting, prioritizing, and critiquing. These are the micro and macro goals of product, although coordination often overshadows both.

I have great respect for those who excel at the minutiae of product. Very few people have the intellectual stamina, talent, and mandate to perfect a product. With that said, critique is an easy skill to learn and one of the most obvious skills to over index on. Even so, very few products ever really get “AB tested to death” and most products get stuck at some modest level of polish. Getting to perfect requires time that most businesses can’t afford and a dedication to craftsmanship that is hard to sustain.

Managing the grand vision is its own challenge. The most obvious part of managing the grand vision is turning it into a plan - feature development, business strategy, talent allocation, and roadmaps. Less glamorous, but more critical, is educating the team on the grand vision and the plan even as they evolve.

In order to effectively deliver product, the team needs to be continuously educated on what the vision is and consulted on how we will get there. This takes a huge amount of time and requires constant, often repetitive communication.

As a junior product person, you will likely spend a huge amount of time coordinating the vision and will mostly express your creativity in the minutia of the product. This can feel like rote project management, but these are critical parts of managing the grand vision.

Transparently, I have a lot to learn about product. I held onto specific end states too tightly instead of the grand vision. This worked well while junior, as I could easily turn the vision into a roadmap or a feature, but I was too timid while evolving plans because of the coordination and morale cost. I also should have been more humble letting customers inform (not dictate) mid term goals, and more flexible about evolutions to the vision.

Venture: Low coordination, high ambiguity

Venture, to which I am newer, is a different beast altogether. Venture is much lower coordination even in larger firms and success, while seemingly secured at investment, is only confirmed years later. You cannot prove your eventual success today, so great investors perfect their process.

I tend to bucket investors into six categories (although they overlap substantially and there are successful investors in each category.)

  • Product: Evaluating product direction and implications for market structure, intuitive understanding of the customer
  • Engineer: Viability analysis and an understanding of how technical details impact market structure
  • Futurist: Strong perspectives on where the world is going
  • Financier: Intuitive and analytical understanding of the market and product economics
  • Heat Seeker: Discover, track, and win the hottest deals
  • Angel: Identify unique talent before anyone else

Time spent is also highly variable by firm, stage, and strategy. As a junior investor, you're likely sourcing (happy hours, scraping LinkedIn, helping friends), diligencing (generally much more fun than I expected), and supporting general partners.

Personally, I spend over 50% of my time meeting founders and learning from them. Founders are usually obsessed, often brilliant, and generally well prepared.There is hardly a greater joy than learning from an articulate, optimistic obsessive.

As I'm no longer exclusively thinking about one vision, I have to intentionally develop a perspective on many products, categories, and themes. This is part of the process. For me, the best perspective building happens through rigorous conversations with colleagues and founders where we hammer through complicated subjects, dissect assumptions, and explore possible scenarios. Online research is foundational, but can be a black hole, while writing helps solidify ideas and forces an opinion.

This process informs your perspective, but unlike engineering you won’t know the right answer for years and unlike in product you don’t own the grand vision.

Final thoughts

This is not advice on how to succeed at each. For instance, product managers need to be obsessed with the customer, engineers need to innovate and code review, VCs need to back the right founders. This is just the advice I give to help others understand how each role feels based, of course, on my own experiences.

I've been fortunate to love each role, but it took doing all three to appreciate the differences. Do you want control? Like managing visions? Comfortable with ambiguity?

I hope this helps and, as always, feel free to reach out.


Comments hosted by Twitter