The Value of Building Granularity into Product Development
I suspect first we will have to define what is meant by granularity. This means that we plan, manage, execute our work at a more granular or detailed level. This applies to the work itself; it’s not just “execute test” but design the test, plan the test, execute the test, and evaluate the test (at a minimum). This also applies to looking at time. If you’re looking at time, then improving granularity means planning and managing work in days instead of weeks or minutes instead of hours.
The first benefit and I believe the most significant but not often discussed, is that when you get more granular, you naturally become more thoughtful about your work. Try this experiment…take a day that you’re in the office but your schedule isn’t run by meetings. Plan it out to the minute (12 minutes for email, 5 minutes of meeting prep, etc.) and then measure it throughout the day. What did you learn? I’ll bet you learned something. For example, almost every time I do this experiment, I learn that I overestimate the time required for big strategic tasks and underestimate how much time I end up in email. Increasing the granularity of designing or planning or executing or measuring our work makes us smarter about that work.
In an organization with a two-year product development cycle, everything was planned in terms of weeks. One step took 7 weeks, another 2 weeks, and so on. We increased the granularity from weeks to days. We didn’t change any deadlines, but only asked people to be more specific. If they said a task would take two weeks, is that 14 days, or 10, or 5 days with a large buffer? That thought process and conversation made everyone smarter about the work.
This is how intuition and instinct is developed. A chef doesn’t have to measure out 7 grams of salt. They have done it so often that they know exactly what 7 grams looks like. Through practice and precision, our brain can learn amazing things.
The next reason that increased granularity is helpful is that it helps us see problems. This is especially important in product development, to spot problems early because time is not recoverable. When you want to ship a product is not a date that should continuously slide unless the customer expectations are the reason it is sliding. If you have a problem, and it takes a month to notice it, you cannot recover that month. What makes this more challenging in product development is that you often have lots of parallel work, and that means problems can occur independently and essentially “stack” your delays. If your process is highly iterative and has built-in loops, such problems waiting for the loop to complete can add an entire loop to the process.
But when you have granularity, you can find problems while they are still small. You can find them while small, they are not only less impactful, but easier to fix. To use an analogy, if you are driving a long distance, the difference between high granularity and low granularity is the same as GPS versus checking the map when you stop for lunch. If you are using the former, the granularity of comparing where you are against where you should be is near-continuous, and if you make a wrong turn, or miss a turn, it is relatively easy to fix. If you’re only checking a map when you stop, then you have low granularity, and you may not know that you have a problem until you see a sign that says “Welcome to Montana.” Now, you have a much bigger problem to fix.
In product development, the low-granularity version is often to use the “gate” process as your checkpoints. These are meant to often be quality checks to make sure there are no problems and therefore we can continue to invest in the program. Unfortunately, there are several problems. Because problems often occur too late to truly fix them while small, we’ve now lost time and can’t afford the time to go back and fix it properly. So we plow ahead since the customer/market date isn’t moving. In these instances, the gate is never really closed, hence my quote “a gate that never closes is just a passage.” Another problem is that you choose to truly fix it, but it’s far more expensive or difficult to fix because of the day. Instead, finding a small problem and then fixing a small problem is a far more efficient and effective approach.