On a recent product prototype project, we introduced an experienced developer to the team. It was this person’s first time on a prototyping project. The gist of product prototypes is to take the core vision of a product and turn it into a working application in the least amount of time possible, usually 6 weeks or less. We know that these projects are different but to someone new to this type of approach the difference required a significant shift in thinking. I focused most of our one-on-one time mentoring this developer on why the prototyping approach was difficult and how to shift their mindset. I found the contrast so interesting and deserving of a blog post.
Before we can get into the differences, let’s look at a traditional developer mindset. When working on a new feature request we think about building a quality implementation with a polished experience. We look to write production-grade code that is readable and easily maintained for future programmers. We try to address the known edge cases and make sure we have automated tests to verify they’re implemented correctly. We know the product team has done their work and that this feature request has gone through sufficient design and review. We trust that what we’re being asked to build is good for both the product and its customers.
That works great for mature products that already know their market and user base. This is not the case for prototypes. With prototyping, we don’t definitively know our market or ideal customer though we do have lots of assumptions. The purpose of the prototyping process is to validate as many of these assumptions as possible with the least amount of time and effort so we can find our product-market fit. It is key for the entire team, but especially developers, to understand this purpose and align our efforts to collect the highest quality feedback in the least amount of time and effort.
Armed with this knowledge we can look closely at a few development practices and explore why they make it hard on developers when first trying to prototype.
Defined Problems and Solutions
With traditional projects, product owners have established roadmaps for features and releases. As developers, we implicitly trust that a product owner knows the best business approach and is directing us purposefully. There is more certainty about what problems we’re solving and the type of solution needed. Thus it’s rare to question either the problem or the requested solution.
With prototyping, both the problem and the solution are based heavily on assumptions that can easily be false. Product owners often will speak about both confidently and developers unfamiliar with prototypes will blindly take these as proven facts and not suspect they are assumptions.
A prototyping mindset would examine these assumptions and ask how they have been validated. Ask directly what problem a feature is solving. How does the proposed interface or functionality address it?
The scope of a feature has a significant impact on many aspects of product development. As scope increases, so does development costs, time, and complexity in the codebase. With prototyping keeping down cost, time and complexity is key to a quick turnaround.
On most projects, the scope has already been defined and planned out on a product roadmap. Developers aren’t given the ability to reduce scope as it’s been sufficiently planned and approved. Traditional development thinking has us happily building all that a product owner is asking for, while occasionally throwing out additional ideas to improve the feature, making it more robust. I’ve been that developer offering ways to enhance a feature and each time to adds to scope.
When traditional developers shift to work on prototypes, we won’t fully factor in the benefits of scope reduction when discussing a feature. A key opportunity to save cost and time is lost.
Following our thinking on the defined problem and solution, we want to ask if a feature can be scoped down? Is there a way to build part of what’s being asked for initially? If we view this feature as an experiment on one of our assumptions, what’s the least we can do to validate it?
I find that this is one of the biggest wins for good prototyping teams as the benefits of tiny scope compounds as we work through the feedback cycle. Knowing we will refine and expand on what works allows the prototype to dial in on the best solution with the least effort and time. Adopting this mindset is not natural for those used to a traditional development approach.
Most software projects are driven by KPIs or other established business metrics. On prototypes you will not usually have enough activity to use metrics in this way. Thus it’s a common pattern for the product owner to rely solely on the product vision as a sufficient measure of success and doneness for a requested feature. While I do agree that the vision is the ideal starting place, we still need to know what sort of feedback to collect to measure success. The traditional developer mindset doesn’t consider measuring each feature by some metric.
A prototyping mindset asks what sort of feedback we can collect to validate that the feature is successful. Can we measure user acceptance? Does this change improve the product in a measurable way?
The Simplest Thing That Could Possibly Work
This popular phrase from Ward Cunningham fits perfectly with prototyping. Unfortunately, traditional feature development makes this difficult. You may start with a heavy design process where you try to anticipate all the ways that this feature may need to evolve. This leads to future-proofing where you likely overengineer the implementation in an effort to make future change easier. The problem is that you can’t predict the future and you spend more time on something that may never occur. You may hear someone invoke the phrase YAGNI in these situations. Though many software developers to try to avoid this unnecessary work, we still don’t naturally embrace the simplest thing that could possibly work.
Not only do we want to embrace the simplest thing that could possibly work, we want to go further. Remember, this is a prototype. You can employ tricks and short-cuts that allow you to get to your goal faster, which is validation. Do you really need to implement all the edge cases? What if you faked some part of the interface that isn’t important at this point, especially around testing your experiment? What if you flat out didn’t implement some aspect of the page that seems obvious but you can work around. Maybe there’s a manual way to handle that functionality that you can bear until you prove the feature is worth building out fully? What if you give the facade that you can click some button and wait to see if anyone uses it?
These types of trickery or short-cuts would never fly in a mature product. For a prototype, they can be your secret weapon. Remember it’s about how fast can you prove the feature is valuable.
This dovetails tightly with building the simplest thing that could possibly work. Feature polishing is what I consider all the extra effort to polish the experience, to get the pixels perfect. Building great products involve this attention to detail and care. We not only build an amazing experience, but we also craft our code to the best it can be. As developers, we stand out when we can work this way and I encourage all developers to hone this ability.
On prototypes, this effort is premature and should be deferred. The time for refactoring and polish will come when a feature has proven it’s worth keeping. It is better for the prototype and the product to focus on speed in turning around these ideas to get feedback faster.
From my experience, this seems to be the hardest one for experienced developers to come to peace with. Once you’ve sharpened your skills to produce software at that level it feels blasphemous to move on from a hastily constructed feature that has clear refactorings left undone.
The ideal prototyping mindset is to focus on quickly turning around the feature without unnecessary polish and refactoring, while not writing bad software. This doesn’t mean you have to make crappy looking interfaces or skip writing readable, understandable code. Knowing when you’ve written enough code to get meaningful feedback is key.
Traditional development teams have a multi-step process that ensures quality and catches potential bugs before they go to production. The number of steps and level of team involvement in this process will add more time and effort to the getting a feature completed. For mature products, this is vital as the cost of introducing a defect or causing system downtime outweighs the added cost. For prototyping, that is not the case as the cost of introducing bugs is dramatically less against figuring out the right experience for a feature.
The traditional mindset for a developer is to have a standard process that they apply to all projects, regardless of maturity. If your standard process is too heavy that will unnecessarily weigh down your prototyping rhythm.
The prototyping mindset explores expediting the process by removing unnecessary steps. Why do we have each step? What do we gain from it? How much review or verification do we really need at this stage?
Since we know it’s a prototype and our primary purpose is to learn from users, do we still benefit enough from those steps? Early adopters understand we’re in an alpha phase and are more accepting of defects and unpolished parts of the app. Taking advantage of this reality frees up the team to move quickly to address user feedback whether it’s a defect or a workflow that doesn’t fit their needs.
Why Prototyping is Hard
When you consider how all of these practices can slow down the prototyping process, it’s not surprising that someone new to prototyping will find the transition difficult. To make matters worse, the effects are cumulative which compound the time and cost of shipping new features. Experienced developers have sharpened their instincts and practices to work best on traditional software projects. It’s not easy to disregard the lessons we’ve learned from those projects.
Prototyping is quite different and requires a shift in thinking. Someone embracing this mindset might finish a new feature in 4-6 hours whereas the traditional approach would take 2-3 days. I’ve seen this difference in effort when comparing similar functionality on prototypes vs mature projects. When you’re building a prototype, this can make the difference between finding traction for your product before running out of funds.