Inside Waldo's product process

Although Waldo is a pretty new company, we’ve consistently shipped product updates every week while maintaining a reasonable workload and respectable hours. We credit much – if not all – of this to our product process.

Like any process, it took a small investment of time to sit down and write out, but the ROI (time saved and clear expectations established) has been incredible. Fortunately, we were able to draw from the experience our team has working with fast-moving tech startups and adapt those experiences to fit Waldo.

The result was a wiki page outlining our product and launch process that lives in Github, which we’ve pretty much copy and pasted below with some context. We’ve covered in past articles how we live and die by Github. If it’s not on Github, it doesn’t exist, as you’ll find below.

Keep in mind, this is the product process that works for us. Yours will likely look a bit different, as no two products and no two teams are exactly alike. That said, we hope ours can provide you with inspiration or at least a starting point if you’re feeling stuck in developing or streamlining a process that keeps your team focused and your product pipeline on schedule.

Our process principles (why create a product process)

Before we dive into what our process is, it’s important to share why we have one. Our goal is to involve the entire team in the shipping process, ensuring everyone has ownership and agrees with the company strategy. Everyone on the team should know what they need to do and what the rest of the team is working on. This creates transparency and helps us develop realistic timelines for each project.

There can never be too many Github issues or too many questions. We value open communication, as you’ll find throughout the rest of this article. Now onward to our actual process.

Roadmap planning

Every quarter, the product team plans the new roadmap together. Then they open it up for discussion with the rest of the team so everyone feels good and confident about what’s to come.

Every week, the team reviews what’s been achieved and decides whether and how we stick to the original plan or if the roadmap needs to be changed.

The roadmap is also shared with our investors because again, transparency is crucial for healthy work relationships.

‍(sprint) weeks

“Done is something that happened.”

Ryan Singer, Head of Strategy at Basecamp

For planning’s sake, we start our week on Wednesday and end on Tuesday. Here’s our logic:

• Because the feature should be released at the end of the cycle, it’s always better to avoid targeting Friday, since it might break and then the whole team has a shitty weekend. This way, we have all of Wednesday and Thursday to get it right.

• It avoids the mind gap of Monday, which can happen when you try to tackle a totally new task and struggle to get quickly up to speed.
  
• Having the 1:1 and planning meeting on Friday allows us to have a feel-good moment at the end of the week and doesn’t disturb the week’s productivity.

Here’s what our weekly flow generally looks like:

Tuesday: Each member of the team presents what has been done in the past week and what will be done during the coming sprint in our Daily Sync calls.

Wednesday:  

• Sprint kickoff
• Release the changelog for the users
• Update our investors on what’s going to be done

Thursday: Thursdays are meetings free day. We want every member of the team to focus on their tasks and nothing else.

Friday: Friday at 10:30 am is the “Lock Plan meeting” detailed below.  

Monday: Resume whatever tasks you were working on last week for Tuesday’s release.

Week plan

Every Friday, we go over our backlog and prioritize the entire team’s task list (which live as issues in Github) together. We start this meeting by looking at our roadmap objectives, then zoom in from the bigger picture.

This helps us remember why tasks need to be done and how they impact our overall progress. It’s during our 1:1 meetings that each team member decides exactly what they’re working on that work, what the roadblocks are – if any – and what support is needed.

Above is an example of what our general sprint board looks like in Zenhub. We go over the issues, close the ones that became irrelevant, review the ones that should be done next, make sure they’re properly specced out, establish the link of dependency between different issues, and assign to one (and only one) person.

Tracking our process in GitHub

Everything we do is trackable with issues on Github, accessible via Zenhub. An issue is done once there’s no more work to do on them. Here’s what done looks like:

• for content issues: the content is in WordPress or Buffer, scheduled for publishing
• for implementation issues: the code is merged AND deployed on the master
• for design issues: the designs have been reviewed by everybody involved

These are defined in our product process wiki page.

1 issue <> 1 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.

Specs

The same issue should not be used for the design and the implementation phase of a sprint. This is probably what causes the most confusion.

Let’s consider an issue about a new feature, i.e. a GithHub integration for Waldo.

• Phase 1: Create an Epic for this feature. Create an issue called “[spec] Design Github integration in web app”. This issue should have 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” (and moved onto the Closed board in Zenhub).
  
  
• Phase 2: Implementation. Open an issue in “backend” called “Implement Oauth for Github”. This issue defines the tech specs to support “[spec] Design Github integration”. Open an issue in “web app” called “Github integration” both referencing “Implement Oauth for Github” as a dependency and “[spec] Design Github integration” as the specs….

The result is a parent (Epic) issue for “Github integration” with two sub-issues(specs) to support it.

A feature implementation issue  cannot be added in This Week until the corresponding Product Spec issue is marked as done. The Epic is only closed once all the issues inside are done.

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 for such:

• p0: Engineer should freeze their current task and fix ASAP. Typically anything impacting a paying customer in a way that’s not acceptable (i.e. sending a wrong email notification to the whole org).
  => Process: interrupt the engineer on Slack to take that new ticket.
  
  
• p1: Finish your current task and take this one next. Typically anything impacting a potential prospect. (i.e. we cannot launch the app for an account who’s interested in trying).
  => Process: put the ticket as the top of This Week. The engineer does not need to be interrupted, but this will modify their workload of the week.
  
  
• p2: This should be prioritized during the next Lock plan.
  => Process: simply add the ticket with the label bug or customer-need at the top of the Backlog.

This means nothing else should ever modify the list of what’s in This Week or Week + 1.

Taking ownership in the process

At Waldo, it’s important that each team member truly owns their area of work. Of course, we collaborate and help each other, but we believe there should be one driver for each scope of work.

That’s why we each manage our own weekly changelog in Github, then share it with the rest of the team. That way, everyone has a clear picture of what we’ve accomplished and what we’re working on.

That’s a wrap

Have questions about why we do things this way? Leave a comment below and I’d be happy to elaborate!

‍