Every week, Waldo develops and ships a gleaming new product update — all while maintaining a reasonable workload and respectable hours.
“We credit much — if not all — of this to our product process,” said Product Manager Edouard de Lansalut.
The process calls for a small investment of time but yields a massive return on investment, he noted.
“At Waldo, our goal is to bring everyone into the shipping process,” he said, explaining that ownership is key. To achieve this level of transparency, de Lansalut and his colleagues rely on a tried-and-true planning tool: the roadmap.
Before the quarter begins, the product team crafts the new roadmap together, choosing two or three primary objectives to anchor their efforts. The roadmap includes a list of contributing projects and a rough outline of weekly action items.
“Every week, the team reviews our progress and adapts accordingly,” de Lansalut said.
Projects are broken into consumable pieces, typically assigning two or three bite-sized deliverables to each person involved. Finally, the roadmap is shared with investors and the sprints are readied for kickoff.
WHAT WALDO DOES
Waldo is a testing platform that aims to let anyone create, run and maintain fully functional, automated, end-to-end mobile tests directly in their browser. Created for mobile teams who care about building beautiful, consistent mobile experiences for their users, Waldo strives to help app teams ship better apps with fewer bugs.
‘Done is Something That Happened’
In the spirit of the weekly sprint, CTO and Co-Founder Laurent Sigal cited an inspiring morsel once spoken by Ryan Singer of Basecamp.
“Done is something that happened,” Sigal said, expounding on the vision behind Waldo’s weekly sprints: a continuous cycle rather than a beginning and end.
Included in this vision is a Wednesday kickoff and Tuesday conclusion.
On Tuesdays, in preparation for the coming sprint, the product team agrees upon a “lock plan,” which outlines tasks, tickets and demos. The team uses Github to align their plans — making sure to compare notes on the scope of the projects at hand. Next, they scan the calendar for personnel details like upcoming PTO and holidays to ensure the plan is manageable.
“We start the Tuesday meeting by looking at our roadmap objectives, then zooming in from the bigger picture,” said Sigal. “This helps us remember why tasks need to be done and how they impact our overall progress.”
SIGAL EXPLAINS: THE IMPORTANCE OF A SINGLE ASSIGNEE
“A Github issue should always have one and only one assignee. We have default assignees for each area: tech, product, and content. Each of these assignees is responsible to triage and assign issues to other people. They’re the overseers of these areas of the product process.”
On Wednesdays, the sprint officially commences.
“Each member of the team presents what has been done in the past week and what will be done during the coming sprint,” Sigal said. “We put a big focus on deliverables — the output of your sprint should be something you are proud to demo to the rest of the team.”
“The output of your sprint should be something you are proud to demo to the rest of the team.”
In the days that follow, product shipments begin, allowing for time to peer review, test suite updates, update documentation and communicate with customers. The process is repeated until the final update is shipped and the following Tuesday begins.
“Features are often released at the end of a cycle — this system avoids targeting Friday,” Sigal explained. “This gives us all of Wednesday and Thursday to get it right.”
If something breaks, the weekend is a wash. Furthermore, “Monday mind gaps” are a real and unavoidable phenomenon, Sigal noted.
SIGAL TALKS: BUGS
“The only interruptions we can add to the section of our sprint board labeled ‘this week’ are for bugs or customer support issues. There should be three kinds of priorities — p0, wherein the engineer should freeze their current task and fix it ASAP; p1, wherein the engineer finishes their current task and takes this one; and p2, wherein this should be prioritized during the next ‘lock plan.’ This means nothing else should ever modify the list of what’s in ‘this week.’”
Ownership 101
At Waldo, ownership is the crux of the product process.
“It’s important that each team member truly owns their area of work,” said Sigal. “We collaborate and help each other, but we believe there should be one driver for each scope of work.”
To support this culture of ownership, Github is the source of truth, said Sigal.
“Github gives everyone a clear picture of what we’ve accomplished and what we’re working on,” he said, noting that issues are tracked on the platform until they are considered done.
To illustrate his point, Sigal broke down a new feature: a theoretical Github integration for Waldo.
“In phase 1, we would create an Epic for this feature,” Sigal said. “We would create an issue called ‘design Github integration’ in ‘web app’ with the label ‘design’ — this gathers the UI/UX designs of the feature, as well as the buy-in from the tech team that the feature is feasible.
“Once the designs are ready and tech is aligned, this issue is marked as ‘done,’” he added.
Next comes the implementation phase.
“We would open an issue in ‘backend’ called ‘implement Oauth for Github,’ said Sigal. “This issue defines the tech specs to support ‘design Github integration.’
“Next, we would open an issue in ‘web app’ called ‘Github integration’ — both referencing ‘implement Oauth for Github’ as a dependency and ‘design Github integration’ as the specs,” Sigal continued.
The result is a parent issue for “Github integration” with two sub-issues to support it, Sigal concluded. The parent issue is only closed once all the issues nested within it are considered done.
“Here’s what ‘done’ looks like: The content is published, the code is merged and deployed, and the designs have been reviewed by everyone involved, ” Sigal said.
