Our team spent some time last week reviewing our marketing and messaging. As it often does, the topic of process, specifically scope management, came up.
We were outlining a few examples of how our teams work with our clients on scope management and how we explain software development when Kristin jumped in to summarize her perspective. I’m paraphrasing here but she expressed it something like this.
“Ok, I get it. We’re having our basement at home finished right now. Just last week, I met with several contractors. One said it could take a couple of months but they couldn’t give me an exact end date or price. Another one gave me a very precise end date and cost. They are a larger company, have more employees and will likely cost us more but…”
At this point I cut her off, politely — I think.
See, the house construction metaphor works in a few isolated cases when describing how to build software and a software-based business. However in most cases it is a terrible metaphor. In Kristin’s example, the gap between her two potential vendors is mostly created due to limited staffing and timing resources.
While there are a few unknowns in the project, each of these contractors has likely built hundreds of basements just like hers. Sure, the price of 2×4’s could increase by $1 or a wall may need to be moved. Maybe a few ugly messes are uncovered when they start the demolition work. However, in the end it’s still a basement and will likely always be a basement. And this is where the metaphor falls apart.
Scoping software development is monumentally more complicated than building a basement. Developing innovative, intelligent software is not so cut and dry. Now, let me explain.
What is you decided you wanted to build a spaceship. You’ve written up your specifications for your spaceship. You’ve built a few parts and tested a few things. You have pretty pictures of what the spaceship will look like and even experimented with what customers are willing to pay for rides on your spaceship.
The problem is that two weeks into building your spaceship, we all figure out you don’t need to build a spaceship. What you actually need is a paddleboat. Oh, and there was a moment when we thought a skateboard was the answer.
How did we figure out you actually needed a paddleboat? Well, we started building, we talked to customers, we iterated, we learned. We learned that the vehicle we’ve building only needs to cross a river, not go to space. We also learned your customers wanted a lower cost option, etc.
In the early days of building a new software-enabled business, learning has to be one of the top items on your list of goals. Through early stage learning you discover what you actually need and what your customer actually wants. If what your business requires is really a paddleboat, you cannot risk spending unnecessary time building a spaceship. At Band of Coders, our teams are very much a part of that early learning process and are often key players in uncovering what it is you truly need to build.
We could, of course, keep our heads down and build your spaceship. Some software development shops do that; however, we never want to protect preconceived notions at the cost of building what you actually need. Our teams need to surface those learnings quickly. We want to help you learn, and ultimately build the paddleboat rather than deliver on the incorrect plan to build a spaceship!
Coming to these “paddleboat” conclusions and making the necessary adjustments can be messy. It often requires tough conversations and sometimes pushback. It’s much easier to keep quiet and build that spaceship. But while building the wrong product really well can feel good, as a company we take no pride in that.
Scope, requirements, and specifications are all required parts of building software — but so is learning! Make sure that learning is part of your process and planning. I recommend you go so far as to build it into your compensation models. Discuss how important learning is with your potential development team. Most importantly, make sure you choose a team who is going to help you learn that you should be building a paddleboat, not a spaceship! No one can afford to be overly protective of yesterday’s best guesses.