Web to Print Implementation meet the concept “minimum viable product”

On July 21, 2010 by Jennifer Matt

Technology startup strategies have improved since the 90’s (thankfully!). One of the many strategies Web 2.0 startups here in San Francisco are utilizing is the concept of “minimum viable product,” as a go-to-market strategy and an alternative to typical waterfall product development. A minimum viable product is just good enough and feature rich enough to […]

Technology startup strategies have improved since the 90’s (thankfully!). One of the many strategies Web 2.0 startups here in San Francisco are utilizing is the concept of “minimum viable product,” as a go-to-market strategy and an alternative to typical waterfall product development.

A minimum viable product is just good enough and feature rich enough to be useful so that you can GET REAL FAST. A startup by nature is creating something new and therefore it’s important to admit you don’t know what is vital to the product until you get real customer feedback. The minimum viable product says, put it out there BEFORE you waste a lot of time and effort building what you think you know.

How can we use this in implementing web to print solutions? I said this in my white paper: Insider Perspective: 10 Web to Print Mistakes to Avoid, get real fast! What I mean is don’t over think, over configure, over theorize about how your customers may or may not use the solution – get it in the hands of customers as soon as possible. Web to print only provides value if your customers can use it.

We know a lot about our customers, we can guess how they want their print job even when they leave out details, etc… but believe me, you don’t know how/if they are going to use this new ordering system. Don’t waste a lot of time and effort customizing a solution before you get real customer feedback. It pains me to see printing organizations pay for software customizations that never get used because they believed the product was unusable without x or y feature. Admitting you don’t know can be liberating!

Deploy a minimum viable product and then configure based on customer feedback rather than on theories. This approach impacts your relationship with your web to print vendor, implementation can’t be done in a single shot. Request a quick pilot and then reserve professional services over time so you can iterate on the initial implementation.


6 Responses to “Web to Print Implementation meet the concept “minimum viable product””

  1. Tim Kelly says:

    This is great advice. At RSA, we focus primarily on the corporate in-plant customer (education, finance, government, manufacturing…) rather than commercial printers. These customers often want to start with ERP integration, shipping integration and customizations they view as critical. Our recommendation is to walk before they run.

    We often recommend an installation that focus on two areas – make it easy for users to submit or select a print ready document and streamline production by sending jobs directly to the printer without re-ticketing. We roll this out to a pilot group of high volume or strategic users.

    As volume grows and users gain experience, the system can then be fine tuned and expanded with integrations, additional modules and further automation. An organization should not view a web-to-print solution as a one time installation. It is best to plan on building the solution over time. To do this, they need a product that can be expanded to meet their needs and a vendor with an installation strategy that supports long term development.

  2. Jennifer Matt says:

    Tim – thanks for the comment.

    I like the analogy of trying to eat the elephant in one bite (impossible). I think print providers get very excited about the possibilities that web to print can provide (most of this fueled by listening to too many sales pitches ;-) This can lead them to lose focus on what they really need to accomplish (provide a self-service ordering platform for their customers).

    Unfortunately there is frequently a GAP between what sales folks say is “possible” and what implementation folks know is “feasible.” It takes a confident vendor to say, DO LESS in order to achieve long term success.

  3. Ryan McAbee says:

    This post highlights the current meme of “always be shipping” and Google’s always in beta development can also apply to a printer’s implementation of Web to Print. After all, shouldn’t customer’s know what they want/need better than anyone else?

    Thanks for the advice (again)!

    • Jennifer Matt says:

      Ryan – Customer’s sometimes know what they want. Remember a web to print company’s customers are typically printers, but the product is for the printer’s customers. How many web to print providers get to talk to the printer’s customers? A web to print implementation’s success is highly dependent on the printer’s customers adoption. Good vendors know this and can stand up to the endless print related feature requests and push to get the product into the hands of printer’s customers ASAP so the real evaluation can begin on the most important metric of all USER ADOPTION. If nobody uses it who cares if it automates pre-press?

  4. I think you must have been eavesdropping on my phone call this morning, Jennifer!

    The shop I was speaking with currently has no web-to-print system and was thinking of spending $100k+ for a one-off, custom solution (based on their needs, I think that price tag was low-balled). Besides the expense and extended development time, they would be gambling that whatever was delivered—a big question mark there—would satisfy their customers. More than likely it would not and the development roller coaster continues.

    Given that no solution (custom or not) will ever be a 100% perfect fit in relation to budget constraints, customer needs and shop requirements, it makes huge economic sense to test the waters with something that works “good enough” and is available now. In many cases, the difference between “good enough” and “perfect” is often one where the same end goal is achieved but by an alternate means.

    As you point out, valuable customer feedback will be gained with a “good enough” solution. If nothing else, this will help improve design criteria should the shop decide to pursue a one-off custom development project.

    Of course, I would argue that the one-off custom development approach will not yield an acceptable ROI for most printers compared to using an inexpensive off-the-shelf system (with or without some trade-offs), or even eventually investing in having the off-the shelf W2P software modified to better fit some unique needs. For some a custom solution may be the only choice, but for the vast majority it is not.

    Plus, being able to supply print buyers with the benefits of web to print technology today beats waiting a year or more while competitors pull ahead with “good enough” solutions.

    Steve Ciesemier

    • Jennifer Matt says:

      For the record I’m not tapping your phones ;-)

      WOW – haven’t heard anyone considering a custom built solution is a while, in the world of cloud computing and open source software – why would anyone build something from scratch ever? I don’t remember where i heard it but it was someone like Larry Ellison from Oracle said that organizations have established processes, then they decide to invest in technology to modernize. The mistake they make is that they take their offline processes and try and force the software (through lots of customization investment) to fit their existing processes. Larry or someone like him said in the long run its actually better for the human processes to mold to the way the software works “out of the box” because then you’re on the standard trajectory of the software platform and can benefit seamlessly from all the upgrades in the future.

      Building a custom solution at this point is like creating your own electrical grid. You incur all the costs of the infrastructure and maintenance.

© Copyright 2014 WhatTheyThink. For reprint information, please contact us.