Business

Why Move the Prototype Earlier

There is a “right spot” for the design and product investment. Too early and you’re generating endless loops of revisions that show you either don’t understand the outcomes or the technology. Too late and you’re starting to implement work that hasn’t been proven to be on-target. While the majority of a discussion on finding this exact point for your organization should be tuned to your needs, let me make an argument for why pulling it earlier than you think is going to pay off.

What is a Prototype?

Let’s talk about what the prototype is and what it can be used to accomplish. I’m talking about a visual representation that demonstrates software workflow and functionality. Some people think that this should be semi-functional and built in the framework of the actual implementation. That sounds like a lot of unnecessary work to me. Consider the plethora of applications that are offering design and prototype functionality, sometimes for free. In it’s simplest form, the prototype is:

  • A view of your software that looks real from about 10 feet away
  • The video under your narration of the user stories
  • A medium in which to discuss how it works and what it does, internally
  • A tool for presenting and validating product vision, in the market
  • Part of the deliverable to the Development team

Why is a Prototype Necessary?

I wanted to write about why the prototype needs to be earlier in the process, but it occurs to me that there are so many who aren’t using them at all! For those that already see the benefits of prototypes, skip this section. For those that don’t feel like a prototype isn’t necessary—or can’t get over the hump of doing them—I challenge whether you believe in product-market fit! Here are some poor reasons to skip the prototype stage in software development:

My product is so simple that people can imagine it with just a verbal description
If this is true then you get a pass! But it’s not true. People have horrible imaginations and this level of fidelity can’t be trusted to make smart business decisions.

We don’t have to talk to anyone. We’re certain that we have the right solution
Hubris, friend. Exactly 100% of the companies I’ve been at have made huge mistakes building features and roadmaps without sufficient market knowledge. If you’re right, then the research will bear it out. Have the courage to investigate why you’re wrong before demanding that you’re right.

There will be no loss between the vision and needs of our stakeholders and the actual implementation
I’ve had this happen a couple of times. But I stopped betting on it after my first failed startup. The complexity of running a real business that depends on new functionality driving revenue reduces the likelihood of this happening exponentially. This is risk that you shouldn’t tolerate.

We don’t know how to do prototypes without wasting time
This is a solvable problem! There are literally programs and colleges teaching just this exact thing! If you don’t have a role in your organization that is competent here, it’s past time to make this key hire. A really good contractor that you trust can do this, but I’ve seen this approach go sideways more often than not. If it takes weeks to get revisions then you’ve got the wrong person doing this.

We tried a prototype once but we spent forever arguing over it and it never got to development
Ha ha! Time to shutter your business. If you can’t agree on what to build you’re either in the wrong market or have the wrong people. I can’t say this one kindly because it is so key: if you can’t build a product when building costs are incredibly cheap, then you can’t build a product. Period. Go home and rethink your life.

Moving the Prototype Earlier

Developing a good prototype requires more than just the UX and design. When you lay out the information architecture and piece in the buttons, copy and workflow, you realize that you can’t just fake it. (You may realize it again and again!) You can’t create a prototype and be honest about it without really uncovering the majority of the aspects of the functionality you’re planning—it’s a gating function. It forces your UX and Product roles to think all the way through projects and make sure they’re considering everything. This is exactly why you shouldn’t wait until development is about to begin to uncover and resolve these issues.

So will the prototype be wrong at first? Yes. Is there risk that you’ll trash a project because the prototype failed? Yes! Is there work in managing exceptions when you have to change a prototype significantly to make the project viable? Of course. But in the current vernacular, this is a “safe place” to make those mistakes and explore your best thinking to resolution. In a way, the more that hits the editing room floor, the more you can be confident that what you are doing is spot-on.

  • MARKETING – Easier to map market opportunities to the planned solution. Drive clarity in the go-to-market plan
  • SALES – Leverage longer sales cycles to “demo” planned and actual product functionality. Build client confidence that you are well into the plans to address emerging needs.
  • PRODUCT – Iterate by getting better customer and market feedback earlier. Refine down to real value by filtering out bad ideas early on.
  • DEVELOPMENT – Optimize Dev time to be 100% on-target. In practice, it’s difficult to revisit with v2 functionality.

The bottom-line and most salient argument for moving the prototype earlier on is this: you can’t afford to wait until you’re in development when you find a blocking issue with the solution. It will cost time and confidence and it’s easy to be overcome by the pressure to adopt adjacent quick fixes that can cost you precious outcomes.

But Are Early Prototypes Anti-Agile?

If you’re reading this as being a waterfall-style approach let me provide some light into how you should implement early prototypes. The Agilists seem to advocate for solving these problems with the designer, UX and development team members at the start of a sprint, armed with outcomes and general strategy from the company. The conclusion of that team will rarely be to prototype—rather frustration or a jump to implementation. The early prototype is an exercise with stakeholders, a UX designer and the product owner. Iterations here can be cheap and fast. I’m advocating pre-development but not without development. This is gloriously agile for the Product/UX team and gratefully requires little investment from the Development team. The prototype should not be implemented without guidance and consultation with architects and trusted front-end specialists—that would be foolish. But the iterations and scope can be done without significant or regular Development participation. Short answer: agile, but in advance of the normal Development team process.

© 2020 Ben Schmuhl | WordPress Theme: Cosimo by CrestaProject.