“I am a Product Manager at Two Sigma.”
Most of the time, when I introduce my job to others, I get curious and confused stares. So, what does a product manager do–either at Two Sigma or at other tech companies? How does product management differ from engineering? And how should a new college graduate think about which career path to choose?
As a recent graduate trained in both disciplines, as well as a former Two Sigma software engineering intern who now works as a product manager, I empathize with the confusion, especially since there is no such college major as “product management,” and the terms sometimes mean different things from one company to another. By addressing these questions, I hope this article will provide some helpful perspective into the choice between the two roles, as well as a reference point for those wondering which career path makes the most sense for them.1
Note I will proceed to make a number of generalizations about what it means to be a product manager and a software engineer. They primarily capture my personal understanding of the two positions at companies I’m familiar with and are certainly not universally applicable. The differences highlighted in this article intentionally accentuate how the two roles differ for guidance purpose, so please be mindful that their differences are usually much fuzzier in reality. I recommend reaching out to employees working in the specific role at the specific company that you’re interested in to get the particulars that are missing from this piece.
What does a software engineer do?
Software engineers (SWEs and engineers are used interchangeably here) design, implement, and maintain software systems. While the exact software varies from search infrastructure to trading engines, depending on the company and the team, the day-to-day work of most engineers follows at least a subset of the steps in a standard software development lifecycle: planning, implementation, testing, deployment, and maintenance. An entry-level engineer is usually responsible for developing features of a larger product or system while participating in operational tasks such as being on-call for business-critical applications, monitoring system performance, and fixing bugs.
What does a product manager do?
Generally speaking, PMs at tech companies aim to create software products that customers love. However, the mapping between products and software is not always straightforward. In the most basic case, the mapping is one-to-one, as in a mobile game application, where the software program is exactly the app that players download and use. More likely, several pieces of software map to one product. For instance, Google Search is a complex and mature product that consists of multiple software programs from backend services to frontend interface, yet this complexity is abstracted from the users who simply interact with Search as one tool. Finally, the mapping between software and products can also be one-to-many. For example, storage offerings at Two Sigma all rely on a common foundational layer, so this foundational storage platform is a piece of software that maps to several user-facing products.
Furthermore, a product is often more than a composite of software systems, and involves user education, product strategy, design, marketing, etc. In this sense, each piece of software can be thought of as a car part. Simply putting parts together may be enough to construct a functional vehicle, but the cars we purchase and drive are never the minimally viable prototype. Rather, the cars we see on the road have slicker design and more user-friendly interfaces, complemented with customer support for usage guidance and maintenance. In the software world, product managers are those responsible for providing this integrated user experience.
As a result of the diversity in responsibilities, the work of a PM often does not follow a clearly prescribed path. Instead, it is more instructional and intuitive to describe the PM role in terms of two questions that every PM cares about:
- What to build?
- Why should we build it?
PMs may be consulted on “How to build it?” as well, though implementation mainly belongs to the domain of engineering. Since PMs are the conduit between the users, the business, and the engineers (plus designers or other functions in some cases), the day-to-day work of a PM revolves around figuring out “the what” and “the why” through customer development, and then exploring “the how”–architecture, feasibility, and implementation details–with the engineers. Concretely speaking, the schedule of a PM is often packed with various communication and relationship-building engagements. Nonetheless, PMs may also be involved in driving business strategies, making design mockups, and coding when necessary.
How do the two roles differ in general?
Expanding on the job overviews, this section compares and contrasts the two roles side-by-side along dimensions that are important to making career decisions. Again, be mindful that differences are purposefully accentuated to provide clearer guidance. In reality, there is often less of a dichotomy, especially if you seek out projects that require a combination of SWE and PM skills. Regardless of your job title, you are the architect for your actual day-to-day work and it’s definitely possible to get the best of both worlds according to your preferences!
Nature of work
While multiple engineers may collaborate on a feature/product, and there will be many teamwork opportunities such as code reviews, each engineer usually has designated responsibilities and is the point person for specific tasks. On the other hand, a PM needs to constantly seek inputs and consultation from others. Although a PM may assist in driving certain engineering deliverables forward, he/she is rarely the sole person responsible for them. Note that responsibility is distinct from accountability. Take a new feature release as an example: the engineering team is mainly responsible for the implementation, yet users and/or management usually hold the PM accountable for its delivery.
Technical gaps vs. product gaps
To address technical gaps, SWEs often need to evaluate and decide among different technologies and implementations. In comparison, to fill in product gaps or identify product opportunities, PMs usually invest in streamlining the end-to-end scenarios, talking to users, testing out products, and aligning with key stakeholders. Such distinctions in focus organically lead to collaboration between PMs and SWEs. For example, the PM could supply inputs to the engineering team or help engineers prioritize certain features through product specifications and user surveys, whereas the engineers could make technical trade-offs to deliver features optimized for the relevant use cases.
Timelines
While most of the SWEs have regular sprints (weekly or bi-weekly) that define their working timelines, most of the PMs have more flexible timelines for laying out long-term strategies. Of course, there are always tasks, definitions, and user feedback for PMs to address immediately. In addressing them, PMs often need to align with engineering sprints to deliver specifications and artifacts for the engineers to execute. A successful PM is helpful and supportive to the engineering team from day one. Consequently, her working timeline is usually informed, though not limited, by the engineering timelines.
Deliverables
SWEs generally have frequent deliverables ranging from small bug fixes to incremental progress towards a more complex feature. The user impact of each engineering deliverable may vary from none (e.g., maintenance jobs) to significant (e.g., new feature releases). In contrast, customer-facing deliverables on a product level are often less frequent (release frequency is heavily dependent on the life-cycle of the product), but the user impact of each product deliverable is likely to be substantial.
Scope / Ownership
An entry-level SWE usually starts with a quick and well-defined ramp-up (about one month), followed by gradually expanding scope and ownership. An entry-level PM, however, usually has a much longer ramp-up (e.g., at large search or social media companies, entry-level PMs typically go through rotations that last for up to two years). This longer ramp-up is necessary because decision-making from the PM side generally requires more context. As mentioned above, though both SWEs and PMs can meaningfully impact user experience, PMs are usually held accountable for the end-to-end user scenarios.
How do the two roles differ at Two Sigma?
While the definitions and distinctions mentioned above apply to my experience at Two Sigma, product management is a relatively new discipline here, and it’s constantly evolving–even across our teams. Since the coverage of the PM team at Two Sigma is still sparse compared to that of engineering, an engineer working in an area without a dedicated PM may take on PM-like work, whereas a PM working in an area with limited engineering resources on some project may participate in software development. As a result, these two roles may be less disparate at Two Sigma than elsewhere, allowing employees more personal freedom in choosing what they want to focus on.
These two roles may be less disparate at Two Sigma than elsewhere, allowing employees more personal freedom in choosing what they want to focus on.
Which role should I choose?
First and foremost, neither one is guaranteed to be better–I love my job and I have many SWE friends who love theirs! The key is finding the role that will make you happy and successful in the long term. You could ask yourself the following three questions when contemplating the right option for you either at Two Sigma or at other tech companies:
Do you enjoy the pure craft of software development or do you enjoy interacting with a multitude of teams?
Be honest with yourself! If writing elegant code is your true passion, then becoming a SWE is the way to go. On the flip side, if you want more variety and wish to take on tasks beyond software development, then the PM role would likely be a better fit.
Side note: How your colleagues think of you may differ depending on whether you are a SWE or a PM. Whereas Two Sigma values the contributions of both SWEs and PMs, in some tech companies, SWEs may be considered more technical and are thus more highly respected; in other companies, PMs (especially senior PMs) may have more influence because engineers are less involved in discussions around “the what” and “the why.” Company culture and environment is a separate topic and should not impact how you pick your career path; however, it could be a deciding factor for whether you want to pursue your preferred career at a certain company.
Are you excited about ambiguity or are you driven by regular deliverables?
For me, ambiguity is both intimidating and inspiring, with the latter outweighing the former. I chose to be a PM at Two Sigma because I see opportunities in having the flexibility to scope out projects I want to focus on and in learning how to swim by directly jumping into the ocean. I understand ambiguity does not motivate everyone, so if you are driven by frequent concrete deliverables, engineering may better align with your preference and present a clearer roadmap for what you can anticipate in your early career.
Are you interested in going deep into specifics or looking more broadly?
Although common perception frames the distinction between PMs and SWEs as generalists vs. specialists, I believe both roles allow you to become an expert. While being a SWE helps you build technical expertise by digging into the nitty-gritty details of systems and software, being a PM empowers you to develop domain expertise by having a deep understanding of industry trends, acquiring intuition for what products to invest in next, and exercising best practices in bringing these product visions to reality.
Final thoughts
I hope you find these experiences and insights on being a SWE and a PM useful when choosing your career out of college. As a final comment, here’s a thought I’ve found helpful in making career decisions–it’s the first of the Top 6 Pieces of Career Wisdom for New Grads (and Everyone Else Too) from Zainab Ghadiyali: Picture your career as a painting, not a ladder. No matter where you start your career, every experience adds a stroke to the canvas. Therefore, don’t fret too much about each individual stroke, and before long, you will be surprised by just how much you’ve achieved and how expansive your painting has become.
Want to learn more about working at Two Sigma? Visit our Careers page for company info, open positions, and more.
