Prototyping: Let’s prioritise it!
“If a picture is worth 1000 words, a prototype is worth 1000 meetings.”
— Tom & David Kelley
Often in software industry we try to solve problems which come from various domains such as finance, media, logistics, etc. There might be multiple approaches to solve a problem and each approach can possibly be developed using different technology stack. But the most fundamental trick to solve a problem efficiently and effectively is to comprehend each and every word of the problem statement and go beyond the text in order to understand larger business intent; and finally working with different stakeholders to find an approach for optimal balance between three crucial components of puzzle:
1. Users’ Desirability
2. Technical Feasibility
3. Business Viability
Regardless of how you manage a project, the above is somewhat basic standard practice in managing IT projects and measuring success. The journey to find the optimal balance between three variants as mentioned above is little more complex. In plain text, it can be divided into five major stages as shown in the diagram below.
We often get confused between these stages, why they exist and what role they play in success of product/ platform development overall. Hence I sat down and try to break the whole process into three major sections that might help to understand where each of the stage fits.
Based on focus area, the five stages above can be grouped into three main functional sections:
- Discussion Phase: POC, Prototype
- Decision Phase: Development
- Direction Phase: Pilot & Production
As you may possibly notice that now-a-days we talk considerably less about "Discussion phase", whereas "Decision phase" goes through cycles of overthinking. The main reason to write this article is my constant observation where people / organisations are undervaluing "Discussion stage" and rushing through "Development stage" to deliver something which keeps them revisiting "Decision phase".
What we may need to remember is that the scope of learning and changes should decrease as the product matures increasing stability. This is similar to a coin spinning down a funnel. Each reduction in scope allows for a faster iteration.
Software development priorities can evolve as the project matures. One important concept to explore is the inverse relationship between the scope of learning and stability. This sounds like a far stretch but has a simple and logical explanation. True freedom to learn and apply what is learned requires freedom to introduce change. Significant changes undermine stability. Stability is gained by limiting the scope of change in the learning process.
We want to always encourage a fast rate of learning but reduce the scope of changes incurred as the product matures.
Recently I asked a question to few senior developers/ stakeholders, a very simple one, “Are you working on a product or platform in your current role?” And the answers were very confusing, and in some cases it was very evident that this has never been discussed at all. Another very basic question was "Have you done a costs and risks assessment of your current Tech Stack?" And in most cases there has been no formal discussion around this topic at all. This shows how much focus is on delivering a product, and how little we talk about the foundation that matters in long run. You might may just wonder what these question has anything to do with development of an IT solution? More specifically does it matter for POC and Prototyping ? The answer is yes, and all similar questions must be discussed with team very early on.
Just to give you a perspective, we all have witnessed how crucial the question might on product vs platform. For example, Apple lead the way of transforming from product focused company to a platform ecosystem company, whereas Nokia failed to capture the idea and remained product focused company. The result, Apple went from brink of bankruptcy in 1997 to a Trillion dollar company in 2019, whereas Nokia went from world's leading cell phone supplier in 1997 to someone left fighting for the scraps in 2019.
Now think of all those hundreds of lines of codes written with a confused philosophy where team wasn't sure about if they working towards product or platform, it’s something that cannot be fixed in a short period of time even if you add extra developers.
Setting right philosophical expectation along with desired technological implementation is what “Discussion phase” focuses on.
POC or Prototyping is not just about making a quick piece of code to work and prove a point. It is an "Initial Validated Thrust" that sets the acceleration and direction of the entire development; and that is why we must not underestimate it.
“Proof of Concepts are like using the scientific method in software development. You have to design your experiment before you begin testing your hypothesis.”
Every major development has some sub-sets of problems that need answering in advance, way before business can formally start to look at desirability or viability of product itself. These sub-set of problems may consist of unknowns at code level, design level, architectural level etc.
A proof-of-concept might be a small project created to test whether a “certain” idea or theory about the product can be implemented. For example, when you don’t know if a feature can be built, you test the idea’s feasibility by creating a POC. This is the only stage that does not need any formal interaction or deliverable with business or end customer. Hence the team has flexibility to try solving all the sub-problem that has potential to turn into nasty surprises later on. Another example of POC is to look at a technology that might better suit to solve a problem in hand, as compared to what's in play within team right now. It might need little research into new technology, asking questions on forums, and engaging team to get a general feel about it. POC actually helps you save money, time and effort: Knowing if something possibly works leads to a lower risk of failure, Allowing team to get acquaintance with something that hasn't been tried before gives more acceptance later in the process and so on.
You might have noticed that POC and a prototype are often used interchangeably, but they really mean different things. A prototype’s main purpose is to help in making decisions about product development by reducing the number of mistakes or discrepancy with desired outcome as agreed with business or end customer. While a POC offers you a model of just one product’s aspect, a prototype is a working model of several aspects of the product.
“The prototype provides an analysis test bed and a vehicle to validate and evolve system requirements.”
Building a functional prototype before actual development is beneficial for both development team and business. Both parties gain an understanding of whether the solution is the right fit, get an opportunity to work with each other to see whether their thought process align, and can gather useful data to inform the next steps. Prototyping also decreases development time by allowing corrections to a product to be made early in the process.
By giving engineering as well as business a look at the product early in the design process, mistakes can be corrected and changes can be made while they are still inexpensive. Equally, if either party don’t gather any evidence that a solution will deliver value based on what prototype delivers, business can always walk away before the “sunk cost effect” impels you to carry on regardless. It’s not always clear how far should one go and how much effort should one put into the prototype before moving on to the real thing. Striking the right balance can be tricky, and there is no fool-proof method. It really does depend on the size and scope of your project.
Prototyping and Agile both involve making incremental improvements over multiple iterations, but they’re not quite the same.
Prototyping involves iterating at the design and planning phase to make decisions that are used to steer development. The prototype is separate from the product, and developers start afresh when they begin coding the product.
In Agile, the iterative process is during the development phase. A Minimum Viable Product (MVP) is created and then tested and improved over multiple cycles. Essentially, the MVP is like a prototype itself, except it is not discarded and is instead continually updated until it becomes the final product. Agile focuses on software development, while prototyping focuses on design practices.
In conclusion, regardless of methodology like Agile, XP or Lean, we need to understand and value of POC / Prototyping stages. We also need to engage as many people at this stages to make product/platform development more inclusive. The time spend in discussions, validating and gathering feedback is vital to save money and time further down the development process. It also increases reliability and credibility as there are possibly less surprises during the stages that follows, hence more likely to meet business expectations.
Paul T. Buchheit is an American computer engineer and entrepreneur who created Gmail. He developed the original prototype of Google AdSense as part of his work on Gmail.
References:
https://www.efunda.com/processes/rapid_prototyping/intro.cfm
https://devsquad.com/blog/what-is-rapid-prototyping-and-why-is-it-used-in-development/
https://www.justinmind.com/blog/rapid-prototyping-isnt-helpful-or-is-it/
https://medium.com/@klappy/lean-expectations-poc-prototype-mvp-140749383fd4