A Long Overdue Lean Designs Post Mortem


In 2010, inspired by the success of the mockup tool Balsamiq, I started working on a competitor called jMockups. My original goal was basically to build a Balsamiq clone, but instead of it being downloadable software it would be web-based. I named it after jQuery.

After a while I realized that competing head-on with Balsamiq was a bad idea so I pivoted to building a high fidelity mockup tool – one that would create mockups that looked like real websites instead of sketches – and I renamed the project Lean Designs. Instead of competing with Balsamiq, I’d be competing with tools like Photoshop that a lot of designers use to design sites before building them. And as an added bonus, Lean Designs would also export your high fidelity mockup to HTML and CSS, saving you from having to manually code up the design when you were finished. I was pretty excited by it.

Here’s an early demo of Lean Designs:

As you might have guessed from the title of this post, things did not go well.

I never wound up writing about what went wrong – mostly out of embarrassment – but reading about my mistakes might save of some of you some heartache with your own projects.

First and foremost, Lean Designs didn’t solve a clear pain point for a specific group of users. If you had asked me back then who Lean Designs’s audience was, I would have said something like: it’s for developers who want to design a website without writing HTML/CSS, it’s for designers to create a high fidelity mockup of their websites before coding it, and it’s for everyday people who want to create a simple static website but don’t want to code 😱.

These are three very different usecases and Lean Designs didn’t solve any of them well. For example, for developers and everyday people who want to create a website, having a What You See Is What You Get (WYSIWYG) web design tool where every element is absolutely positioned makes it extremely hard to create a well-designed site. I touted on Lean Designs’s homepage how easy it was to create beautiful websites with it, but almost everything created with it looked terrible.

If you asked me which of those use cases was my focus, I probably would have said Lean Designs was a Photoshop replacement for designers to create high fidelity website mockups. But… I am not a designer. And I’ve never used Photoshop to create high fidelity mockups. I read online about how many designers use it, but I had no expertise in the problem I was trying to solve. And if Lean Designs was truly for designers to create high fidelity mockups, why did I build an export to HTML/CSS feature that would never be used by these designers in a production website?

One way to mitigate this is to do customer development: to get on the phone and meet face to face with people in this market to learn about their real problems. I never spoke with anyone in Lean Designs’s target audience to verify my assumptions. This is ironic given that Lean Designs is named after the Lean Startup movement, a big part of which is to do customer development to avoid making incorrect assumptions.

I also didn’t research any of my competitors. I rationalized it by saying to myself that I didn’t want to be influenced by what was currently on the market. To this day I’m still learning about competitors that existed back then that I had no idea about.

I formed jMockups LLC to add an element of seriousness to the project even before the site had launched. That’s $500/year to operate in Massachusettes.

I paid hundreds of dollars for a logo that I never wound up using because after I bought it I realized it resembled a swastika:


When I later renamed the site to Lean Designs, I filed a trademark for it with the help of a local lawyer. He also helped write its Terms of Service. 💸

With all of these administrative things taken care of, I proceeded to spend months building the first version of the product.

I thought I was being innovate by blindly following my vision for the product, but I was being extremely naive.

When I received feedback about jMockups on HackerNews, I took every bit of praise as validation that the product was on the right track. Same thing when I announced the pivot to Lean Designs.

The first version was completely free. I wanted feedback – any feedback – and thought that the best way to do that was to get as many people using it as possible. Feedback from free users can be very misleading; what you really need is feedback from people who will pay.

Eventually I transitioned to a freemium model where you could create a limited number of mockups for free or unlimited for $9 per month. This was a tool that I was aiming at professionals and I charged the same amount as a burrito at Chipotle.

The only marketing I did for it was to create a blog where I only posted about feature updates. I should have been writing – or paying someone to write – content that would be interesting to my target audience (whoever that was).

And for the few people that did use it and did pay, I eagerly implemented almost every feature request in the hope that each one would turn the tide on my failing product.

I was in a mastermind group at the time, but we spent too much time talking about features and not whether the Lean Designs was viable in the first place.

I didn’t pay close attention to metrics nor did I look at what people were actually creating with the site.

Finally, I spent way too much time trying to turn what I knew to be a flop into a successful startup. It’s hard to know sometimes whether an idea is bad or whether you just need to keep pushing, but in Lean Design’s case I kept at it way too long.

After about a year and a half and hundreds of hours spend toiling away on nights and weekends, I stopped accepting new users, put up a notice that it would be shut down in a few months, then killed it.

The upside of my experience with Lean Designs is that I picked up a lot of new technical skills and learned a lot about what not to do which I later applied to Lean Domain Search and other side projects.

Was it worth it? Could I have learned these things by reading blog posts like this one when I was deciding whether to work on Lean Designs? It’s hard to say. I’d like to think so. Maybe some things just have to be learned the hard way.

On that note, if anyone reading finds themselves working on a project with similar issues and is looking for feedback, don’t hesitate to drop me an email.



Screen Shot 2015-12-20 at 5.09.51 PM.png

If you want to learn about venture capital and the world of enterprise SaaS, it’s hard to beat SaaStr, a bullshit-free online resource for all things SaaS.

Reading it over the last few months has really opened up my eyes to how the industry works. The topics range from raising capital, managing companies, the economics of venture capital firms, pricing, hiring, company culture, and more. Check out their best posts for the highlights.

Also, if these topics interest you, you can subscribe to new posts in your favorite RSS reader by searching for “saastr.com”. Highly recommended.


Assumptions kill startups

The most common theme in my early failed startup attempts was that I made a lot of assumptions about how my ideas would play out in the real world that later turned out not to be true. And while I have no plans to work on another startup, I do chat with a lot of folks working on startups so I want to elaborate on this lesson learned in the hope that it will benefit a few of you future founders out there.

A hypothetical startup

When I was working heavily on Lean Domain Search, I used a service called Commission Junction (CJ) to manage its affiliate programs. CJ’s internal performance reports were terrible so I wound up building a script that signed in, scraped all of the reports, and then presented the key metrics to me in an internal dashboard. It helped me quickly gain insights about Lean Domain Search’s performance that were painful and time consuming to glean from CJ itself.

This gave me I had an idea: what if I built a startup that helped other companies using CJ gain similar actionable insights from their CJ data? They’d pay my startup $XX/month and I’d help them make more intelligent decisions about their affiliate programs.

I added it to my Workflowy “Startup Ideas” list and fortunately that’s all that ever came of it.

What assumptions did I make?

Here are a few:

  • Scraping CJ does not violate their Terms of Service
  • Companies would be willing to provide me their CJ login credentials so I could scrape their performance reports
  • I’d be able to figure how how to securely encrypt and decrypt those credentials so a database breach would not also lead to their CJ accounts being compromised
  • That there are companies that are dissatisfied by the reports CJ already provides
  • That there are a lot of them
  • That they’re also willing to pay for a better analysis
  • That they’d gain enough value after becoming customers to stick around for a long time
  • That they would somehow find my service
  • That CJ wouldn’t just change their reports to include the improved analysis my service would provide


You could make long list like this for almost any startup. Imagine making one for Uber or AirBnB when they were at the idea stage. The lists would be massive. But… if you don’t think through your assumptions and how you’re going to solve them, you drastically increase the odds that your startup will fail. For this CJ idea, if any one of those assumptions turned out to be insurmountable, the startup would probably fail.

If you had asked me about my assumptions when I originally came up with the CJ idea, I probably wouldn’t have been able to come up with the same list of assumptions as I did above but likely would have thought of at least several of them. The more experienced you get, the more you’ll be able to identify the pitfalls in your ideas. This is also why you should get advisors who can help you identify areas that you’re overlooking.

One final point: a lot of the issues in the list have to do with customers and their need for a service like this. Many of these assumptions can be validated using customer development techniques. To learn more, I highly recommended the Lean Startup book by Eric Ries.

If you’re bouncing around any startup ideas, feel free to reach out and I’d be happy to provide feedback on them.


From Max Brooks’s World War Z:

Ask anyone how the Allies won the Second World War. Those with very little knowledge might answer that it was our numbers or generalship. Those without any knowledge might point to techno-marvels like radar or the atom bomb. Anyone with the most rudimentary understanding of that conflict will give you three real reasons: first, the ability to manufacture more materiel: more bullets, beans, and bandages than the enemy; second, the natural resources available to manufacture that materiel; and third, the logistical means to not only transport those resources to the factories, but also to transport the finish products our to the front lines. The Allies had the resources, industry, and logistics of an entire planet. The Axis, on the other hand, hand to depend on what scan assets they could scrape up within their borders.

When we think about war we often imagine the combat taking place on the front lines but just as important is the infrastructure that gets the soldiers there and supports them after they arrive.

When folks learn that I was in the Air Force many ask if I was a pilot because that’s what people tend to think Air Force personnel do. However, only about 3% of Air Force personnel are pilots; almost everyone else supports the pilots in one way or another.

I got to experience this first hand when I worked at the 87th Mission Support Group at Joint Base McGuire Dix Lakehurst in New Jersey. The Mission Support Group consists of six squadrons, each with a important role that supports the base as a whole: the Communications Squadron enables personnel to communicate with each other, the Security Forces Squadron keeps the base secure, the Mission Support Squadron handles personnel administration, the Logistics Readiness Squadron keeps the vehicles running and the planes fueled, the Contracting Squadron ensures contracts are awarded on time and without issue, and the Civil Engineering Squadron oversees the facilities. Without any one of these or a dozen other units on base the pilots would not be able to fly and the planes would not be where there they need to be.

Similarly, to have a successful software business it’s not enough to simply crank out code. You need to have fast servers, excellent marketing, helpful support, solid documentation, a clean, intuitive design, and a whole lot else. Like the squadrons in the Mission Support Group, these are not what you normally think of but they are critical nonetheless.

It may be worth thinking about what the key support elements of your business or life are that enable you to do what you do. Are you giving them the attention they deserve? Is there anything that you could be doing better?

Photo courtesy of Flickr.