When Steve Jobs rejoined Apple in 1997 he came back with a framework he called a "2x2 matrix".
On the left side of the matrix, he had "Desktop" and "Portable". On the top he listed "Consumer" and "Professional". That matrix gave Apple four main types of products to focus on and an easy way to prioritize product decisions.
If you look at Apple's products it's easy to see Job's matrix at work.
But prioritization of time and resources isn't unique to a big tech company. For software development teams, understanding where to spend time can make the difference between hitting roadmap goals and falling short. We find that giving our developers frameworks like the 2x2 matrix is a way to make sure they're making the right decisions on every project, whether that's choosing how to solve an integration problem or whether or not to fix a bug.
Here's an example of how we enable faster and better decision making in the bug situation. It's a great example of using time as efficiently as possible and maximizing return on developer time.
There are basically four different meaningful scenarios when you encounter a bug.
1. Lots of users are impacted and the solution is obvious.
This is the red alert, SEV 1, urgent scenario. The bad news is that a lot of people are impacted. The good news is that we know exactly how to fix it. No brainer. Fix now!
2. Lots of users are impacted but the solution isn't obvious.
This may also be a red alert situation, but the outlook isn't so good. We have a large group of users that are impacted by the bug, but we're having trouble finding the exact source of the issue, or a way to fix it. It's a definite gray area. The bug needs to be fixed eventually but the resources we deploy to find a solution and the speed with which they do it has to depend on the nature of the bug. If it's impacting the core functionality of the product, "soon" means ASAP. If it's just a minor inconvenience or isn't widely noticed, "soon" might mean within the next few days or weeks.
3. Not many users are impacted but the solution is obvious.
No need to sound the alarms here. Not many people are impacted by the issue and the solution is evident. The "soon" here means, we'll get to it when we can.
4. Not many users are impacted and the solution isn't obvious.
These are the bugs we're just going to live with. The work of trying to understand the problem, identify a solution, and deploy it just isn't worth it.
However, there is an exception to the rule - not all users are created equally. If a small group of people are impacted by a bug, but it's an important group, you should fix it immediately. Say you manage a banking app and a bug is only impacting 5% of users. No big deal, right? Maybe not. But if those 5% of users are your high net worth accounts, you probably want to address the problem immediately. Bugs don't happen in a vacuum. Business and technology context matter.
These are the types of frameworks and considerations that enable simple and faster decision making. And while we expect every engineer at The Gnar to take advantage of this framework and thinking, we also have founder oversight on every project. As you can tell just from this one bug example, gray areas still exist even with the best frameworks. Combining those tools with senior thinkers who understand product goals and business implications leads to the best all around outcomes.
Pete Whiting is the Head of Growth and Client Service at The Gnar Company, where he leads business development, marketing, and client service activities to help companies build high-quality custom software. With over a decade of experience at the firm, Pete specializes in driving revenue growth and ensuring high utilization of development teams through strategic go-to-market and product marketing initiatives.
Prior to joining The Gnar Company, Pete held executive roles in operations and marketing at firms such as Dispatch and MeYou Health. He also spent five years at Vistaprint, where he served as Director of Product Marketing and Strategy for the Asia Pacific region, accelerating annual revenue and gross profit growth through data-driven planning and multi-channel marketing. Pete’s career began in engineering and management consulting, including seven years at Deloitte Consulting leading growth strategy and post-merger integration for global industrial and high-tech clients. He holds an MBA with honors from UCLA Anderson and both a Master’s and Bachelor’s degree in Materials Science and Engineering from Brown University.
