Feature Reviews for Software Projects

Feature reviews are a way to share engineering projects with internal stakeholders, focusing on progress made, remaining work, and any challenges or risks that might need help. We started these back in my days at Palm. I've been running a variant of this for my current teams at Tableau and thought it would be helpful to describe this idea a bit better.

Origins at Palm

First, a little background on the origin story for Feature Reviews which we ran for the software projects at Palm Computing. Palm was a hardware company which meant most projects were driven by the manufacturing schedule. In this environment, one key learning for software teams like mine was that schedule is not going to slip. It was a good forcing function though; whatever software was ready by the cutoff date, that's what we're shipping with. We could do patches later, but everything really had to be done.

This meant we were essentially following a waterfall process even for software and even with our attempts to make our project more incremental (pre agile). Our solution was to add some intermediate progress updates which we'd share across teams and with our engineering and product leadership. We wanted to combat this waterfall idea of a long development time being a "black box" until the result popped out at the end:

It's a simple concept - just add Feature Reviews as intermediate checkpoints along the way:

These reviews were useful for bringing together the right set of peers and leaders, to report in a sense "here's what we're building." I remember we fine-tuned them to just cover the most impactful or risky projects, especially those that had both desktop and handheld components. Hosting these reviews regularly also helped in cases where we needed to make course corrections or scope reductions to ensure we would achieve the deadlines.

Fun fact #1: While writing this up I remembered something about life on a software team at a hardware company. All our project end milestones were "GM" (Gold Master), because our code was literally going to be cut to a master CD-ROM or master device ROM. Everywhere I've worked since has really called it "GA" (General Availability).

Fun fact #2: My team owned the desktop applications including Palm Desktop, and we liked to include easter eggs in the product to list all the people who built it. We even got our names into some official product marketing screenshots!

How to run a feature review

Here's my suggested outline for holding a feature review, including the audience and what you should cover:

• Owner - Prepared and led by the feature team (engineering & product).
• Audience
  • Stakeholders (including leadership, architects, field)
  • Peer and related teams
  • Other interested people in the company; looping in those who're interested in what you're building that you want to keep informed and query for feedback
• Contents
  • What are you building (setting context for those who aren't familiar)
  • What's the status, show live demos
  • What work is remaining (schedule discussion)
  • What open questions or potential risks should be discussed
• Frequency - This will depend on your overall project timeline, but we found every 4 or 6 weeks to be about right. So out of a roughly 12 week release cycle, we'll meet 2 or 3 times.
• Logistics - Pay attention to the usual important details for a meeting like this, including advertising in advance, keeping the conversation focused, and capturing recording/slides/actions to share afterwards.
• Outcomes - The team should agree ahead of time whether the purpose is mostly sharing status, or whether there are any specific decisions you need.

The review contents will likely change a bit as you make progress. The first review can focus more on requirements and planning, but the big value in future sessions is to show off what has been built so far. For one project I'm leading, our first review was more top-down (requirements, design, dates, who's working on it, etc.) with the demos at the end. Then we flipped it (bottom-line up-front style) and jumped right into the demos first with project status/logistics to follow.

As an engineering manager, there's a bonus for me here which is giving your team the spotlight and encouraging them to participate and drive the demos. Presenting your work is a great skill to have and these feature reviews can be safe spaces to practice.

Comparison to the movie business

I had a random thought comparing this idea of feature reviews for software projects to the "dailies" that are used in the movie business. AI chatbots tended to agree with me, no surprise there!

Copilot wrote this comparison:

Feature reviews in software projects and dailies in movie production both serve as regular, structured opportunities to review progress, engage stakeholders, and mitigate risks. The main differences lie in their frequency, scope, and the nature of what's being reviewed. Feature reviews are broader and less frequent, supporting complex, multi-phase software development. Dailies are immediate and focused, supporting the fast-paced, high-stakes environment of film production.

Comparison Table: Feature Reviews vs. Dailies