Product Engineering at WorkOS

When we’re asked what “product engineering” means at WorkOS, we say that product engineers talk to customers, understand problems deeply, map out the market and the competitive landscape, build products that delight, and do so at high velocity. That’s all accurate but it doesn’t fully capture the type of work that product engineers actually do on a day-to-day basis.

The best way to understand what a product engineer does at WorkOS is to understand our product project lifecycle. It is the full expression of what we mean when we use the term product engineer.

Our lifecycle borrows from 37signals’ Shape Up methodology which we’ve refined to suit our operating principles and engineering culture. It charts a project’s evolution as a hill: shaping pushes the boulder up the hill while implementation rolls the boulder down the other side.

It has become the rhythm to our feature development blending speed with clarity and empowering engineers to act as product owners. This post walks through that lifecycle, what it means for the engineers driving it, and why it results in great product. It’s more a roadmap than a prescription, and we encourage product engineers to exercise their judgement in following it.

Project brief

Every project begins with a brief: a one-page document that sets the stage by describing the problem, who experiences it, why we should solve it now, how much time we want to invest, and what questions remain. Engineering managers often write these but they can be written by anyone. Once we’ve agreed as a team that the time is now, the manager assigns a directly responsible individual (DRI). This is the product engineer accountable for transforming the problem statement into a compelling product.

Kickoff

With agreement on the investment and a DRI assigned, we kick off the project. The purpose of the kick-off isn’t ceremony, but clarity. The DRI creates a dedicated public Slack channel. Stakeholders from design, security, infrastructure, go-to-market, and engineers are explicitly added. Context is shared so the right people are aware and engaged. Often, we’ll spin up a synchronous call to ensure everyone is clear on the direction.

We’ll also share the existence of this project to the entire company in #all-product. There’s a lot going on at any one time, and we don’t want the existence of this project to go unnoticed.

Kickoff ensures the team is rowing in the same direction from the start.

Shaping

After kickoff, the DRI begins shaping. This is when a product engineer gets to go deep: reviewing feedback, interviewing users, mapping the problem space, analyzing the competitive landscape, and collaborating with product designers to sketch UI flows or define API ergonomics. This takes days, typically, but large projects can take up to a couple of weeks.

Especially during the shaping phase, product engineers and designers work with the garage door up. The Slack channel becomes the project’s stream of consciousness. Everything related to discovering the best solution gets shared in this channel: UI explorations, API shape, competitive analyses, and regular updates on the path towards the top of the hill.

The output of this work is a Hilltop document, the engineer’s vision for how the problem should be solved. That vision is what gets tested in the next stage.

The Hilltop

The Hilltop is so named because at this point we are at the top of the proverbial hill. By the time a project reaches this stage, the engineer has become the domain expert, having done the research and synthesized input from designers, security, and other partners. The Hilltop document they’ve authored presents a clear definition of the problem and a compelling vision for what the end product could look like.

Hilltop reviews are small, synchronous meetings — usually five or six people to encourage feedback. The make up of this session varies but usually includes some mix of an engineering manager, other product engineers, product designers, frontend engineers, the product manager (we have one!), and our CEO, Michael.

These sessions last between 1 and 2 hours. At times, we may touch on some of the implementation details but they serve primarily as a review of the customer’s experience. Will the API feel intuitive? How do changes to product surfaces reduce friction? Where’s the “wow” moment? The purpose is to pressure-test assumptions and give the DRI feedback, sharpening their vision into a clear north star for the build phase.

Sometimes we decide not to pursue the project. That is a valid outcome for a Hilltop review. Armed with more information, we may decide that this is not the time to pursue this work.

Most of the time, though, we incorporate feedback from this session into the design and move forward with confidence.

Build

With the Hilltop crested and gravity on our side, implementation moves downhill with momentum. The engineer now builds against a clear vision, weaving observability, QA, penetration testing, documentation, and SDK updates into the process. Everything in this stage is guided by a single goal: to manifest developer joy.

To accelerate learning, we make liberal use of feature flags, allowing us to deliver functionality early to design partners. Along the way, engineers share progress through constant demos, whether in the project channel, in a company-wide demo channel, or during our weekly All Hands. This practice of early exposure and continuous feedback ensures that by the time a feature officially ships, it already feels lived-in, tested, and shaped by real-world use.

Ship

Shipping is about more than code hitting production. DRIs are responsible for running enablement sessions with developer success and go-to-market teams, creating runbooks that anticipate common questions, and sharpening how we explain the value of the feature.

From there, we choose the rollout strategy that makes the most sense for the feature. Sometimes this means enabling for 100% of customers. Other times we’ll announce the feature and enable on request, to gather targeted feedback before expanding to general availability.

Finally the DRI works with marketing to ensure the story lands clearly, writing the Changelog entry and for larger features, a blog post.

Post-ship

Getting a new product or feature out to customers is not the finish line. After a launch, the DRI spends the subsequent weeks staying close to the feature. They watch for developer questions in customer Slack channels, fixing any issues quickly and addressing feedback from early adopters. To ensure the impact aligns with the vision, they track product usage, performance, and reliability.

Once the ship has stabilized and obvious points of friction have been addressed, we work larger points of feedback into our team roadmap, archive the project channel, and consider the project done.

Why this works

AI tooling has increased developers' ability to ship code quickly, but building great product requires engineers with product taste and a framework that enables them to design solutions that cut to the heart of customer problems.

Our product project lifecycle — project brief, shaping, Hilltop, build, ship, and post-ship — creates a structure in which engineers aren’t waiting for decisions, but making them. By the time a feature launches, the engineer who built it has become the expert on that problem, worked directly with designers, our product manager, and other engineers, presented a clear vision to leadership and peers, shipped a honed solution to the problem, and enabled the entire team to ensure customer success.

If you're interested working this way, we have plenty of opportunities to do so and would love to hear from you.