This article was co-written by Rob Brazier, Head of Platform Product, and Ben Mackey, Engineering Manager.
Think about the last time you launched a product you were really proud of. What was it about that launch that felt so successful? When we’ve reflected on this question at Grammarly, we’ve noticed a common theme: Each time a launch went really well, there was a strong collaboration between engineering, product, and design. Everyone on the team had high alignment on the problem we were solving for the customer, we knew what the impact of our work was going to be, and we took an exciting risk to create something that didn’t exist before.
What if you could replicate this feeling consistently? What if you and your team could regularly deliver products you were proud of, that made things better for your business, that delight your customers? More precisely, what if you could ship new features you were proud of every six weeks?
In building Grammarly Business, this is what we want all of Grammarly’s engineers, product managers, and designers to experience. But achieving a process that facilitated this was not without challenges. As Grammarly Business was a newer product offering, we needed a process that would let us quickly iterate on features with a tight feedback loop from customers. Instead of using sprints to organize our work, we’ve adopted a framework called Shape Up. It’s helped us empower small teams to make decisions about how to best solve customer problems in a creative way.
We ship features we’re proud of on time
When we started working on Grammarly Business, we knew we had a chance to try a new game plan for building software. We’d assembled a diverse team of amazing engineers, designers, and PMs who knew the product and the customer better than anyone. How could we put our trust in the team to solve problems in their own way?
We came across the Shape Up framework and found that it reflected our experiences of building products we were proud of and gave us the language and techniques to recreate that feeling every time. The philosophy boils down to this idea: Instead of asking, “How long will it take to ship this?” we ask, “What is the most valuable version of this that we can ship in six weeks?” Nothing is more demotivating than not shipping. So if we decide to take on a project, we commit to shipping a working product offering or feature after six weeks. The process frees every member of the team to do meaningful, focused work they are pleased with—and avoid unnecessary context-switching and artificial estimation.
How it works
At the beginning of each six-week period—called a cycle—anyone on the team can “shape” and submit a project proposal. This is a rough sketch of the customer experience, with a focus on understanding and mitigating any risks upfront. For the proposals we decide to take on, we assign a small cross-functional team—one or two engineers, a PM, and a designer—and trust them to figure out the rest. Cycles are followed up by two weeks of “cooldown” time for reflecting and deciding where to go next.
1 Shaping a proposal
While most proposals end up being written by PMs in collaboration with engineering and design partners, anyone on the team can create one. Proposals start with a problem we’re trying to solve—it could be related to our long-term vision, a new concept from customer feedback, or an idea for improving our system performance. The goal of shaping is to outline the solution in a way that sets us up to deliver the most value in six weeks. (Sometimes we’ll group smaller projects together. For example, two or three small technical-debt pitches could become one six-week project.)
During shaping, PMs, engineers, and designers work together to outline the UX at the level of “fat marker sketches” to clarify the edges and boundaries of the main interactions and user flows. With sketching, we can quickly try ideas and throw out the ones that aren’t likely to work. At this stage, we’re focused on determining the “what”—without being prescriptive about the “how.”
When shaping a proposal, we also focus on understanding risk. While the proposal is taking shape, PMs are vetting their ideas extensively with the engineering and design stakeholders to understand what is realistic and what could go wrong. What are the blockers and dependencies? What scope could we leave out? It’s important that at the end of a cycle, we have something meaningful to show for it—so we work proactively to identify anything that could derail the project.
All proposals are publicly available to the team for comments and questions. We formally decide which projects to invest in for the cycle during a leadership meeting with proposal owners.
To illustrate how we implement the shaping process, here are a few real examples from a recent cycle on our team:
Example: Analytics dashboard
Customers had indicated they wanted insights into how Grammarly Business was improving their communication and positively impacting their business outcomes. We knew that it would probably take a few quarters to build a mature version of an “ideal” dashboard. But the great thing about our process is that even if we plan to continue working on a project long-term, we don’t have to wait six months to ship the product offering or feature to customers. Instead, every six weeks we can make iterative improvements.
We decided, based on customer interviews and feedback, that the first version of the dashboard should focus on giving buyers and team managers insight into how Grammarly Business was improving their organization’s overall productivity and communication quality. We also identified several reusable components that we could leverage, including existing definitions of metrics and back-end data infrastructure. For example, rather than creating a new set of events to capture, we used the existing concept of a Grammarly “user session” as a proxy.
Example: Snippets
Another proposal was for a feature that involved letting someone search for a frequently used sentence or paragraph and insert it into their writing. We thought that, especially in a customer-service scenario, these snippets would save a lot of time and help businesses be more consistent in their communication.
When shaping the pitch, we realized that the biggest risk factor was the fact that we had never had a user-triggered interaction like this before. Up until this point, Grammarly’s suggestions were always surfaced by our AI-powered writing assistant. We decided that the best approach would be to ship a simple prototype in six weeks so we could perfect the interaction. (With a higher-stakes project, we typically start with an internal prototype in the first cycle and iterate from there.)
Shaping a proposal forces us to ruthlessly prioritize. To make the prototype as basic as possible, we decided to focus on the UX for inserting a snippet of text from a centrally managed library, and left out (for the time being) the details about how a user would create a new snippet. By de-risking that part of the project, we could spend the majority of our time figuring out how to let users pull up snippets and insert them into their writing.
2 Working on projects
Because the shaping process doesn’t define high-fidelity mocks or the technical design, there is a lot to figure out from day one. The time pressure is on—we want something to ship in six weeks!
We commit to delivering a certain result, and then we give teams complete autonomy over how it gets done. Engineers, designers, and PMs start working together as a single unit right away to rapidly prototype and iterate. No tickets, no micromanaging. But communicating and tracking progress is still important. We’ve found hill charts to be helpful for sharing what stage the work is in and noticing if anything is stuck.
For each work item or “scope,” a hill chart can reflect whether we’re still figuring out the unknowns (going up the hill), or are in the execution phase (going down the hill). The scopes are up to the team to decide. And they can change—for example, as we’re working, we may realize that it would make sense to split one scope into several. We like hill charts because they’re flexible, they don’t add a lot of process overhead, and everyone can see progress at a glance.
Example: Analytics dashboard
When we’re in the hill-climbing stage with a scope, the time pressure of having six weeks to deliver tends to generate a scrappy mentality. For example, while building the analytics dashboard, we found a quick workaround to an issue because we wanted to hit the deadline and ship something to customers.
The particular challenge was surfacing a list of Grammarly Business accounts that were active each day to accompany one of our charts. We realized that to log this data, we would need to build new infrastructure—we didn’t have time for that. Instead, we simply decided to link to the existing “Members” tab, where we already displayed the last login date for each member. We could iterate on this solution later, and it allowed us to ship on time.
Here’s an example of the final analytics dashboard that we’ve shipped to customers.
Example: Snippets
For the snippets project, the team scheduled weekly demos throughout the cycle. They made an effort to get the separate parts of the prototype built and working in a rudimentary way by week one or week two. This helped them make sure there weren’t any big unknowns up front. With the early components working smoothly, the rest of the time could be spent wiring the pieces together with APIs.
Here’s an example of the snippets feature that we’ve shipped to customers.
3 Cooldown
Following each six-week cycle, we have two weeks of “cooldown.” Engineers and designers may choose to pay down technical debt, handle small bug fixes, write documentation, or brush up on new skills. We explicitly do not use this time to assign tasks left over from the cycle—that kind of work needs to be shaped as part of a new proposal. Instead, we trust people to decide what they want to work on during the cooldown. (And if they’re not sure what to work on, we keep a prioritized list of smaller tasks and improvements that anyone can pull from.)
If you’re heavily involved in shaping proposals, these two weeks can be quite busy figuring out where to go next. After launching the snippets feature internally, for example, we wanted to launch it to our beta customers in the next cycle and add some essential features, like the workflow for creating snippets we had left out of the initial prototype. We also incorporated user feedback from our own use of the prototype internally—such as the requests we’d heard for an easier search function. One of the advantages of shipping every six weeks is that you get direct feedback early and often, which helps you stay attuned to customers’ needs and maintain the right course.
The whole team (and beyond) benefits
No process is perfect, and we’re still learning as we go, but so far we’ve found that putting Shape Up into practice has many benefits. Engineers get to own the work on a project from beginning to end and make decisions about how it should be done. Their priorities remain clear and stable over the course of six weeks, and they aren’t expending energy context-switching between multiple projects.
By working shoulder to shoulder with engineers, designers end up feeling more empowered as well. They’re not spending weeks on wireframes only for the engineering team to say the feature is not possible. With an understanding of the limitations from the start, designers are in the driver’s seat, proposing solutions right away as new questions arise.
For product managers, who are always concerned about timelines and resources, this process removes all that doubt and overhead. With the confidence that their team is committed to getting something meaningful done in six weeks, PMs are free to focus on the work that tends to be the most satisfying: discovering, understanding, and envisioning solutions to user problems. And ultimately they get to ship something they’re proud of.
For managers, this framework provides predictability. Since the whole organization is on the same schedule, you know when you need to be in strategic planning mode and when you need to shift gears into tactical execution. One of the most attractive things about Shape Up is that during the six weeks, the whole team is aligned—no changing priorities or questions about what is most important.
Finally, customers also benefit from six-week cycles because they can rely on us to ship improvements frequently and be responsive to feedback. One fact of product development is that there are always more ideas and more feature requests than you could ever satisfy. In a single cycle, we may only focus on a few important opportunities, but the process gives us confidence: At the end, we’ll not only have something great to show for our efforts, but we’ll also feel eager and empowered to take on the next challenge.
Want to come ship meaningful work every six weeks with an incredible team? Grammarly is hiring for various Grammarly Business roles! Check out our open roles to learn how you could help build product offerings that serve 30,000 teams at organizations across various industries.
