Let's say you and your team have unearthed a brilliant idea that involves building an application. It is going to change the way your company operates, penetrate a new market, reduce complexity, increase revenue, and so on. The excitement in envisioning what this idea will become can be so overwhelming that you want to sprint to start writing lines of code. While many of us have been there before, here are 3 reasons not to build that application (just yet).
1) You Haven’t Done Your "Homework"
While your idea may sound great on the surface, how much validation have you completed before writing the first line of code? Have you taken the time to truly define the product vision? There's work to be completed; asking key questions around who you’re serving, the problems you’re solving, benefits you’re offering, key assumptions that you should be testing, and defining the resources you’re working with.
Take time to brainstorm (internally with your team and externally with third parties) and heat map potential features for your product roadmap. All these inputs you gather should be used to generate important “artifacts” or outputs, which may be used to get valuable user/stakeholder feedback before moving into actual development work. Work with frameworks to help validate your ideas such as a Lean Canvas or a Clarity Canvas (pictured below).
Spending a little more time on the front end of a sizable application development project can yield massive efficiencies down the road.
2) You Haven't Discussed Guidelines For Decision Making
In every project there are changes being made, there must be a simple, quick, and effective process to evaluate the changes and discuss tradeoffs.
As Colin Flynn has shared in a previous post, The Change Model can give you that simple process to evaluate the changes and tradeoffs you're making as you build products.
You can think of each circle above as it's own entity, a component of the overall product. Each of these components are tied to each other by a single rope. A rope is a perfect metaphor because it has tension.
A successful product development process has tension in the system. It's healthy. The system starts to break down when there is too much or too little tension (slack) around each component. Too much tension snaps the rope and the product falls. Too little tension and there is nothing holding it together. If each component doesn't work together the product won't feel cohesive.
In order to ensure that each component is being considered as decisions are made, we assign each component an advocate. An advocate's job is to make sure that he/she thinks about how a change may affect his or her's component. While each component needs an advocate, the same team member may be an advocate for more than one component.
As any product grows and matures, the size and needs of the product team change drastically. A startup building an MVP might have a founder, designer, and developer splitting the roles and responsibilities. At the enterprise level, a product may support millions of users and each component could have a team of people being its advocate. Since we have implemented the change model, we have noticed a couple positive things taking place:
- Our clients and our team are speaking the same language.
- The process allows for flexibility in times when it's needed most.
- Decisions are made out in the open vs. in a black box, and everyone understands the trade-offs of those decisions.
- Clients become extremely valuable members of the product team. They have a new found confidence about what they have built, and they often walk away with a process to continue development with their own internal team.
3) You're Not Ready To Iterate
Odds are your hypothesis about how your users will use your product will be incorrect. That's why it's incredibly important to be ready to iterate on your product. Many executives and internal teams focus obsessively on the perfect business plan with far-reaching, high dollar projections. While there's nothing wrong with having a long-term vision for your product, in reality, markets can change overnight and it is impossible to really know how customers will interact with your product or service without seeing them use it. The biggest risk you face as an organization is spending too much time and money on a product that nobody actually wants.
Gathering user feedback fills a gap that market research and predictive analytics cannot - it helps us understand the "why" behind what people are doing. Why are people using one feature four times as often as another? Why are your customers working through the application in a completely different manner than you envisioned? Why do most of your customers abandon at the point of purchase? Or what causes customers to stop using your product entirely? You'll quickly identify and know how to fix problems and go after the right opportunities.
Launching and gathering feedback does not mean offering such a buggy product to where your users don't even have functionality. Instead, focus on building the smallest version of the product (with the most minimum feature set) to solve the problem you’re addressing. The mission is to provide your users with a solution that they can use while at the same time allowing you to test all of your assumptions. Remind yourself that software is never truly "finished".
At Differential, part of our process when building custom software involves dedicating explicit time to the three points I mentioned above. There's value to be unlocked in "slowing down to speed up" and we've found that spending a little more time upfront yields massive efficiencies down the road.
