Early Evidences Vs. Coding ASAP
The implementation of (almost) every software product starts with someone defining what needs to be built and how the software is supposed to behave. So far so good, if it wasn’t for the fact that a (ridiculously) huge amount of implementation work is spent on coding products that have no evidence or indication that the product will be really valuable/usable.
An established notion in the software development world, says that the earlier changes are made in the software lifecycle, the cheaper they get. But at times, all we want to do is to rush into real dev work. This happens especially when there is pressure from other groups/departments to see “progress” being made. Some other times, this can also come from developers doing what they believe is their main and only responsibility: to code. However, as a developer, I care more about my product being successful than about jumping to coding as soon as I can. Furthermore, as a Product person I care more about defining/identifying the right product/feature than seeing “progress” going in the wrong direction.
It turns out, the more user tests, assumption validation and experiments done BEFORE/DURING the product definition (to gather evidences about the value proposition & market-fit & usability) the higher the chances that the product will be successful. This is actually one of the biggest trade-offs when it comes to iterative software development:
Spend time gathering evidences about the product you want to build (and doing necessary changes) VS start coding asap to release as soon as you can
And this needs to happen incrementally in small iterations. When this is done early in the game it is all about gathering evidence that all the hard dev effort will not go in vain later on. Lean Startup is a great example of methodology that focuses on that. Small startups can not afford to build the entire product (even if it is developed in an incremental agile manner) and only after that realize that it is not going to fly. Lean Startup will leverage experiments to reduce uncertainty and validate assumptions. These experiments are No/Low-code tests to determine if the proposition, look & feel and value are going in the right direction.
If you are a software developer, sometimes this NO/LOW code may scare you away, because you LOVE coding and would like to spend all your time doing this. But we, software developers, need to give more attention to this and either (1) ask for evidence that we are building the right thing (from early phases experiments); and/or (2) support and enable these experiments ourselves in order to increase the team’s confidence that they are building the right product.
If you are a product person, the experiments at the beginning may feel like you are slowed down, but this is actually setting you up for success. You should keep an eye on the balance of this trade-off and make sure you sustain a healthy level.
If you are an engineering manager, creating the environment where developers engage more in this type of activity should be on your radar as a very important task. Healthy teams with a culture where they figured out the right balance for this trade-off, are the ones that are most successful at building the products, and at the end of the day, the product is the biggest recipient of benefit .
