If you’ve worked in technology for the last 5 years, it’s likely you’ve come across the skateboard analogy for building products. If you haven’t, the essentials are this—If you think of a customer problem in the metaphorical sense as someone wanting to travel from one location (A) to another location (B), there are a ton things you could build that would help them achieve their goal.

Now, when brainstorming solutions, people have a tendency to jump to fully-loaded ideas; continuing with the same metaphor of travelling from A to B, that solution could be a Tesla. Teslas are among the sexiest, feature-rich, head-turning solutions a team could build that would indeed enable someone to get from one location to another. It’s also the type of solution that a lot of starry-eyed builders want to work on themselves.

The obvious issue with this approach is that most of the time you’re not building for what you want—you’re building for what your customers want. Not only that, but you’re going beyond the scope of the problem you’ve been presented with and risk spending time, money and effort on things your customers may not even need. Revisiting the customer problem will tell you plainly that the customer just wants to go from A to B—that’s it. Our imaginations, ideals and ultimately our assumptions make us think they also need the leather interior, touch-screen dashboard and driverless features in order for our solution to be a success. This is the fallacy that so many builders and teams are learning time and time again the hard way. Myself included.

Unfortunately, building products customers love is really hard; and often times we make it much harder than we need to.

The point of the skateboard analogy is that rather than building the feature-rich, Tesla version of a solution, build the skateboard version first. Focus on what is needed to successfully solve your customer’s immediate pain—in this case, getting them from A to B.

After you’ve successfully solved their core problem, you then get to include them in the process of defining to build next that would improve their experience and ultimately attract more customers like them. When you take this approach, almost always you’ll find that the really cool ideas that you would have prioritized yourself will actually be really low on the wish list of your customers.

Now, part of the problem is that it’s really easy to get lost in Assumption Land early in a project when you have limited customer feedback. Even with customer feedback, often times things will immediately go beyond the skateboard and before you know it your team is wanting to plan out a Tesla build. Now I’m not saying the early stage brainstorming and green-field ideation is bad—it’s 100% required! But how do you get your team to focus and get started building something that isn’t a complete waste of time? How do you define and start work on your minimum viable product (MVP)?

An exercise I’ve found to be super useful for teams I’ve worked with is using a conditional statement when scoping work for a particular project or release.

Now don’t fret, I know reading “conditional statement” sounds like dev-speak and may cause your eyes to glaze over but it’s a really simple concept that just happens to be foundational to technology.

Using your customer problem—make sure you have this clearly defined and validated first—create a statement for you and your team that can be used to evaluate the priority of new features and ideas. Ultimately, this helps your team take a first-principles approach to the problem. It’s kind of like that good/bad scale Willy Wonka uses to gauge golden egg quality.

Continuing with the same example of travel, our conditional statement could be something like, “Our solution enables customers to get from their home to the office, safely.”

Now, take all the ideas for features and functionality that your team has brainstormed for potential solutions and ask yourselves, “Is this a requirement for our conditional statement to evaluate to true?” If yes, it’s in scope. If not, punt it until there is an actual customer problem that supports the need to build it.

Here are a few ideas the team may have come up with when brainstorming their solution for our problem:

• A navigation system
• A sound system
• Something for the customer to stand/sit on
• A chair
• Ability to support 200 lbs of weight
• Ability to support 2,000 lbs of weight
• An engine
• Safety testing
• Wheels
• Rearview mirrors
• Solar panels
• etc.

Now, weighing these against our statement, “…customers are able to get from their home to the office, safely”, there are a lot of things in that list that we could build that are not required for our statement to to be true.

For example, do we need a chair in order to get customers from A to B, safely? Not necessarily, right? A skateboard doesn’t have one. Neither does a scooter. Nor do rollerblades. However, these examples of solutions would all in fact enable someone to get from their home to the office, safely. Right?

Therefore, the scope of work for our first release/MVP might look something like this:

• Something for the customer to stand/sit on
• Ability to support 200 lbs of weight
• Safety testing
• Wheels

You can either trash the other ideas until a customer actually asks for them or move them to a backlog to be reassessed against a future release’s conditional statement. Either way, they didn’t make the cut for this release. If you’re like me and you like a clean backlog, trash them. After you get over the initial anxiety of a lost idea, it feels reaaaaal good.

Now, as they do, things are going to come up as the team gets further into the project. Scope creep is a real thing. To help defend against it, return to your conditional statement. Does your statement need to change? If so, that’s ok. Readjust if necessary. The main purpose of your statement is build alignment on your team and allow everyone to more easily assess how essential new work is to the success of the current version of your project.

One of the unintended benefits of approaching release planning this way is that it gives you a simple summary to not only guide the project team, but also all other team members in your organization. Marketing, sales, support, etc. will all have a quick and easy reference for why the team is building what they are at a given point in time without having to go through the more verbose project requirement docs and/or brief(s).

As customer feedback begins to roll in, you can then begin to shape what the next release phase’s statements might be—assuming of course, the first phase was successful enough to warrant more work on the problem. The next phase of our project could have a statement like, “Our solution enables customers to get from their home to the office, safely, without breaking a sweat.”

There are a plethora of tools and systems people use to get buy-in and alignment with their team. Unfortunately, not all of them work for every person. Everyone thinks/works very differently. In my experience, the simplicity of a one sentence statement has really helped to keep not only the team, but an entire organization aligned on what is getting built and when.

Try giving it a shot for one of your next projects and let me know what you learn.

My last tip for this is that if you do give it a shot, put it up on a whiteboard or wall where your team works and revisit it regularly (stand ups, agile ceremonies, etc) to continue to drive home the problem you’re building for and support your team’s alignment.