The Problem

Some engineering teams can struggle to communicate at the right times in the software/product design cycle or fail to gather feedback at the appropriate level of detail. This can result in churn during the specification phase or missed expectations in QA or delivery, not to mention interpersonal frustration for individual team members. Your team may suffer from this problem if you hear or experience any of the following (exaggerated for effect):

Designer

I wouldn’t have designed it this way if I knew it was going to be so difficult to build!

Engineer

The product specs don’t cover all the edge cases! How am I supposed to build this?

Product Manager

I didn’t need that level of detail - I was just hoping for a SWAG estimate on how big this is.

Engineer

I feel like the team had a lot of nitpicks for my design document. Maybe I shouldn’t have shared it so early on.

Engineer

I saw the UI mocks for the first time yesterday and we’re supposed to start on this work in a few days. I haven’t figured out what we need to build yet!

10%/90% Specifications

To improve collaboration on my team at Transfix, I worked with my team to implement an idea I first learned about from some engineering leaders at Flatiron Health that I’ll call 10%/90% Specifications. The general principle is simple: authors of specifications are transparent about how far along they are in the process of developing their ideas so that others can give them feedback at the right time and level of detail. In practice, on any specification document, the author is expected to label the progression of their thought process in a percentage - this can be any number, but my team has formed checkpoints around specs that are 10% complete and 90% complete.

A 10% specification is the earliest form of an idea that’s ready for input. At this stage, feedback should be directional. Pointing out areas of complexity to be explored or items to reduce or remove is especially encouraged. If a project is driven by a product need, the Product Manager responsible produces a 10% product spec, then the engineer leading the project produces their own 10% spec based on the requirements. Often, the two authors meet and get feedback from one another and 1-2 additional stakeholders within the team, agree on directional changes, then part ways to do the hard work required to take their ideas to the next level of fidelity. For engineering-led projects, the first phase may only consist of a review from a team member with expertise in the area being changed.

A 90% specification signals to others that the idea is mostly thought through and is practically asking for nitpicky feedback. Authors are generally happy to receive it at this stage because they are confident the idea is sound and want to polish it to its best version. This is the time when we bring in other project stakeholders, specifically others on the team who will be working on the project, for a review and kickoff. Labeling a spec as 90% complete at this stage is also important for the team because it indicates that they can still give input if their perspective would shape the final direction.

Implementation

For a large project, a process for developing 10% and 90% specs may look something like this: 10%/90% Spec Timeline

Skeptics of process may see this as heavy-handed or meeting-happy. I agree that teams can implement 10%/90% specs in ways that create long cycle times, but the principle can also be applied within the course of a single day:

Consider a situation where an engineer and a PM meet at the beginning of the day to create a 10% spec (a whiteboard drawing) for a small, 1-person project. They then go away and develop their ideas throughout the day on a shared Google doc, have hallway conversations with teammates to get input, then meet again in the early afternoon to agree on the 90% document and commit to starting the work. All of the same benefits can be realized without weeks of effort or formal requests for comments.

Take what works for the situation at hand and leave aside the rest if it slows the work down without benefit.

Outcomes

This is still an evolving practice but I have some early signals to indicate that this process has improved collaboration on my team:

  • Engineers feel that they are more involved early in the product ideation process and can shape product ideas based on their input and how our systems work.
  • Product Managers and Designers feel like they are not wasting their time producing highly detailed specs that are then changed based on engineering input.
  • Engineers, Product Managers, and Designers have opted to change project directions or scope before getting to high-fidelity designs or many-page documents based on 10% discussions.
  • Engineers are willing to share 10% technical plans without full details because they understand they will have an opportunity to refine them before committing to the work required.
  • Comments on design documents or specs match the level of detail promised by the author - rarely are there nitpicks early in the ideation stage.
  • Meetings at the 90% phase often feel like reviews because the product and engineering owners are in lock step about what’s being built and the effort involved.

Areas for Improvement

There are still a two areas for improvement that I’m pursuing in our process:

  1. Identifying the right stakeholders at the 10% phase: this process can be undercut by feedback that changes the direction at the 90% phase. This often happens because a key stakeholder was not included early enough. We’re experimenting with also identifying key reviewers for each stage on specification documents along with the completeness percentage.
  2. Application to small projects: as stated above, this can be applied at a very small scale without formal documents, but it requires diligence on behalf of the team to communicate about the completeness of an idea, even when writing on a whiteboard.