The Opposite of a Minimum Viable Product

The product that defined itself organically 

I have been fascinated by the “lean startup” philosophy, including the “Minimum Viable Product” concept, about which I’ve written before. Considering our main software product, Silicon Designer, I realized that we never went through a process remotely like that of the “Minimum Viable Product” but instead we essentially built the same thing over and over again, with specifications defined by 50+ clients over 10+ years, and we didn’t even call it a product until it had taken shape as such. “MVP” concepts are still relevant, but I think it’s useful to consider a case precisely the opposite. Although I wouldn’t suggest anyone else do this intentionally, this is one way that software can evolve and products emerge — the story of how Silicon Designer came into being, followed by thoughts about OGP vs. MVP. (There is an explanation of what Silicon Designer is and how it works over here.)

It was once a side-hobby

The co-founders of Silicon Publishing have been building online editing solutions for nearly two decades now, between our 13 years as Silicon Publishing and a few years previously at Bertelsmann. While our initial specialty was database publishing, we were fascinated by the concept of online editing even though, given the very limited capabilities of mid-90s web and print technologies, it presented a rather ridiculous prospect. Like many challenges approached more out of love than practicality, it was something of a hobby.

• When CSS came out, we mapped CSS styles to print styles, ingesting HTML to render print documents.
• When the very first “content editable” tag came out with the IE 5.5 beta, we used it for some crude online editing solutions.
• When drag and drop became possible with HTML browsers and Javascript, we were among the first to map coordinates to create print documents based on web-based design.
• When SVG came out, we were among the first (possibly the very first) to use inline SVG on a web page, with the aim of applying this to web-to-print. (We knew SVG would take over the world: it only took a decade longer than we planned on).

But during the late 1990s and early 2000s, this was something we loved, yet not what the market was clamoring for. The “web to print” functionality we provided from the earliest days of the web was tangential to our bread-and-butter work: database publishing. Our web front ends let users choose layouts and flow data through them on the back end: typically, they did not provide a WYSIWYG editing interface like we do today.

Ralf Bierfischer and the Services Religion

When we started Silicon Publishing in 2000, we had not planned to have any software products: we were a custom development shop and we provided custom solutions. Alissa (our other co-founder) and I had been steeped in the “services” religion from our years at Bertelsmann in the 1990s, and we enjoyed custom development projects.

“Bertelsmann Industry Services” was the name of the company we worked for at the time (now I believe it is “Arvato”), and the President leading our operation was a brilliant, energetic, young and charismatic guy called Ralf Bierfischer. He would stop by our office periodically and inspire us to work harder and deliver publishing solutions with more fervor. Each time he spoke to us, he started out by explaining that we don’t build products, we provide services, that is what we do and what we were meant to do.

I think we were a bit brainwashed by this. Bertelsmann Industry Services did create one product, “Directory Expert” which was a tool for creating healthcare provider directories, but that was the exception rather than the rule. The rule was that we provided services that differentiated our custom-built solutions from product-based solutions by our ability to do unique things, things generally impossible with canned, off-the-shelf software.

Five years of custom development

After founding Silicon Publishing, we set out to do exactly what we had done at Bertelsmann: custom coding, mainly of database publishing solutions. As a small company, this quickly expanded across a wider range of languages and technologies than we had planned. My hobby of XML-based rendition (SVG and XSL-FO) turned into a significant part of our work, although it was tangential to our original plans. We ended up doing a ton of work for Adobe, including putting U3D and DITA support into FrameMaker: we built many solutions that automated document production, some of which produced millions of personalized documents a month. We would re-use some core code libraries but we mainly approached each project on its own terms. True, in some cases we built other companies’ software products, but it didn’t cross our minds to create our own serious product.

During our first five years, we couldn’t have really built an online editing tool. We had become so enamored of Adobe InDesign that we stopped using anything else for automated page composition. While at Bertelsmann we used servers to create print output, InDesign only offered the desktop as an option. We used it in ridiculous ways, forcing some of our clients to run their jobs overnight to produce data-generated content. The process was silly, but the output was higher quality than anything we could achieve with any other tool. And it was not that hard for them to push the button and come back the next day: truly “lights out” automation.

We did build some online editing solutions, but they were neither real-time nor were they completely WYSIWYG. For example, we built a course catalog editor for ACTS Seminaries that offered complete online editing of course catalogs, but the production of print was non-realtime. The web content was instantly updated, but to make the print version someone at the university needed to download the database (which contained many chunks of XHTML) and run it through InDesign (where we had religiously mapped CSS styles to InDesign styles).

We begged Adobe for a server form of InDesign: but we expected to use it for database publishing solutions, which by 2005 had again become the majority of our business (as we had hoped initially). Online editing was in the back of our mind, but not our primary goal.

The seed of a product is planted

When InDesign Server finally came out, we did enhance the scale of our database publishing solutions. It was kind of shocking that existing clients didn’t leave the desktop in droves, but would keep right on clicking the button to come back the next day. Printers (especially in the mid-2000s) have never been known for extravagant investments in technology.

But new clients came in, although we were surprised, since more than half of the would-be InDesign Server prospects didn’t want database publishing — they wanted online editing. Macromedia Flash had reached a level of sophistication and ubiquity where online editing was possible, albeit barely. We were just adventurous enough to try it, and we were surprisingly successful with it.

Thus Silicon Designer evolved into a product not in the “lean startup” way of trying out a concept, but completely organically. We found ourselves delivering online editing solutions to client-driven requirements that had incredible overlap. After developing many similar online editing solutions by steadily improving the reusability of our code, we hired our first developer with a deep product background (our current COO, Aaron Hodges) right at the same time that our core “designer” codebase seemed product-worthy.

We announced “Silicon Designer” at Print 09 and were shocked at the level of interest. Suddenly we were engaged by Shutterfly, Harland Clarke, and Printing.com for very large-scale solutions.

Serendipitous Timing

Where would we get talent with the very rare expertise required for round-tripping web and print content? Adobe did us quite a favor when they pruned some top-notch talent from their InDesign team. We hired developers that we previously had been honored just to meet, and our capabilities increased exponentially. We faced the challenge of improving the product while delivering solutions for demanding companies, with increasingly complex specifications that did not always overlap. We faced all the challenges of growth. It was exhilarating, though, to work on a larger scale with the true world experts at what we were doing.

The entire experience of assimilating so many “real” developers (we hired more than 10 ex-InDesign team members) with our “custom development” developers took Silicon Designer to another level, but it came with a steep learning curve.

Contrast Alissa and myself, who had worked with a “standard 5-day turn time” for the publishing apps we’d built at Bertelsmann, and would code solutions in days, to serious programmers from Adobe who could take two 18-month release cycles to add a feature. Consider testing, continuous integration, and the challenges around coordinating the efforts of 20+ developers on a single project.

We refactored Silicon Designer once, creating a “new core” with an elegant architecture and the first features that had been planned with “product specifications” — in contrast to an MVP approach, there was zero mystery about what features would be valuable to our clients. We had years of empirical evidence as to which clients wanted: it was a matter of listing 50 features we had done in a one-off way and determining which were most valuable to our clients. This was coupled with an analysis of the level of effort required, which was generally easy for us to do, given our prior experience.

The resulting new core initially disappointed us. We had to re-factor a second time to get it right, but thanks to some incredible collaboration and even more amazing developers joining us, we now have an extremely solid product. Organically grown.

OGP vs. MVP

I am making up a new acronym to describe this absurd form of Product Development: the Organically Grown Product (“OGP”). What is an OGP, you ask? It is what results when the product does not start out as a product, but instead becomes a product after the code base reaches maturity in the context of custom solutions.

While the Minimum Viable Product (“MVP”) is a prescription for how to do things in the context of a “lean startup,” OGP is hardly anything one would plan to do, especially in this day and age. Five Year Plans are not even big in Russia anymore, let alone Silicon Valley. OGPs are phenomena that happen accidentally, and I am sure there are other examples besides Silicon Designer out there. If there are startups doing OGP, they are doing so either by accident or by the desire to “bootstrap” and avoid investment. Or perhaps their founders were brainwashed by Ralf Bierfischer.

Commonality with MVP — the “real world” specification

Certainly MVP concepts are still valuable, and some of the benefits of MVP are exactly the same benefits offered by OGP:

• In both cases, there is a fast go-to-market phase. It is simply called a “product” with MVP and a “one-off, custom solution” with OGP. Certainly one-off software solutions developed by small shops are typically minimal, at least in the beginning.
• In both cases, specifications are not from fantasy. Real-world, empirical information feeds the feature development of both product types.

But it’s way different

The major differences between the two:

• OGP specifications are not hypotheses, but are tangible, real-world feature requests. With an MVP someone has to think, “I wonder if the world would want… this!” and the startup is the one defining what is being developed. Then they see whether people will actually pay for what they have envisioned. With the OGP, far less speculative thought is required.
• The timeframes are in opposition. If you want to get rich quick, embrace MVP and go for it. OGP is something that will happen to you if it is right for you; it is not a prescriptive concept but a descriptive one.
• The audience for the OGP, in its gestation period, is not the entire world. Rather than broad feedback from early release, the feedback only comes from clients using their custom solutions. If features overlap among solutions broadly enough, this may constitute a different form of feedback, which is more detailed and less relevant than statistics gathered from the entire market.

Accidents happen and sometimes they’re great

While it came about in an unplanned way, Silicon Designer is a fantastic product and our team’s expertise is now unparalleled in the world in terms of this niche of technology. Getting here was often painful, but we have arrived at a place we are deeply thankful for.

I don’t spend time studying business, generally, and because I’m obsessed with web technology, the businesses that I do find out about tend to be VC-funded startups following MVP practices. I haven’t heard of anyone else quite like us, but I’m sure they’re out there. I would be thrilled to hear about any similar experiences.