Presentation: Engineer Innovation Through Rapid Prototyping

Ramon: This changes a lot from day to day. I am the lead engineer on Vistaprint’s innovation lab, known as Hatchery. We develop products and services that are new to Vistaprint and we do this by rapidly prototyping new concepts and testing ideas in-market to find a viable execution that can prove assumptions in our business model.

My time is split between hands-on-keyboard engineering and management of two other engineers on the team.

Ramon: I’ve given similar talks within Vistaprint to share our process and techniques for quickly making progress on an ambiguous topic. I have found that many teams that are great at optimizing existing systems and handling large-scale operations have a lot of trouble when starting something completely and can be slow to make progress because they use the same approach.

I want to provide some specific tools and techniques to help teams adjust how they attack a problem.

Ramon: Anyone on an engineering team that ever has to develop new products of features where there is uncertainty in the demand.

Ramon: The topics should be broadly applicable and understandable to most anyone in an engineering organization. There isn’t any required engineering knowledge since most of the talk will be process-related.

Ramon: As an architect, it is natural to focus on building a robust, scalable architecture for a new feature or product. The problem is that many times it isn’t clear which features are unimportant and which are critical to success. It’s not about how smart or experience your product owner is, we simply can’t predict what will succeed.

I would expect architects/leads to reconsider how they get started on new projects and to be very intentional about when to jump into designing a scalable architecture. Devising small-scale tests that help validate a concept will help you avoid building unnecessary software, which often complicates and confuses the design.

Ramon: I have attended a number of agile training sessions, and I find it’s very common to talk about how 75-85% of software features that get built are rarely or never used. All the time spent on marginal features has an opportunity cost, so instead of adding more complexity for limited return, we may want to focus something else more valuable.

Great engineering is much more than just writing software and it’s even more than simply translating known requirements. Sometimes the software that we don’t write is the most important.