Skip to content

MB1 – Play 8 – Work only on What is Important

Marc adopted similar principles to me in getting the product to market as quickly as possible. As he says in his book, “do it fast, simple, and right the first time”. Based on my discussions with another tech startup from the north, they have rewritten code number of times to get it right. I do not see this as a problem, as you evolve and your goals change, so should the code, unless you can read the future.

At edocr.com, we had another consideration, how to build without spending money! We achieved this through using open source products as much as possible. In addition, we inherited a technology stack, that each of the team was familiar with, which ensured, low cost and speed to market.

Unfortunately, the “right for the first time”, requires mammoth resource base. I am not talking about 100s! But it require more than one or two developers. In my opinion, your initial customer facing product, should not require the effort of more than couple of developers. Remember, at this stage you are gambling, unless you have a customer who has already paid for your product. Don’t be embarrased to release a product with few known glitches. It’s OK as long as you disclose you are working on them and do have a plan to clear the bugs quickly. By getting a product out to market quickly, you can start validation quickly and your users/customers will not just help you to test and identify bugs, but will also help you validate the product map. But be careful not to build every functionality your userbase asks for. You may end up with a product users like but may not have any chance of ever commercialising it.

Marc speaks about keeping things simple, no fluff as he elegantly put it. He also speaks about their early focus on developing the best possible and easiest to use product; focus on the 20 percent that makes 80 percent of the difference. Whilst I whole heartly agree with this and wish we could have adhered to similar principles, we were constrained in many ways.

Few of the key questions I ask myself before we venture into any further development on edocr.com are:

1. what is the expected return – this is not about putting a scientific figure against an expected ROI, its all about your gut feel. By now you should know your market inside out and know well what could make money and what couldn’t
2. who requested it – if its a customer (better if its more than one) request, and you believe it ought to be provided, yes! but if it was requested by a user that is unlikely to ever pay for you services, think twice before you commit your scarce resources.
3. do you have to do it – perhaps for legislative or any other purpose, including the future failure of your product or its infrastructure. This is no brainer, you got to bite the bullet and commit resources.
4. what about the competition – this should not be a good enough reason. Does it achieve differentiation that will increase value. Be careful in copying your competitors.  The one with the biggest market share and capital will ultimately win. So look for differentiation and try to carve a niche, which may help you discover a short cut that will eventually put you in the no. 1 seat. It does not matter, if the rest of the world does not get this, but make sure you test it over and over.

Couple of areas we are working on at edocr.com right now with comparison to above 4 points:

1. Lead capture – there is a significant revenue opportunity, so this meets the “expected return” test
2. Ability to update documents – requested by customer. Even I within edocr has this need to update our brochures, etc. We have the same requirement from Northern StartUp 2.0, who is edocr.com’s first customer.
3. Limiting “email this” facility – at present, edocr.com allows ability to promote documents by emailing document link to unlimited number of email addresses. Unfortunately, this functionality has been misused, resulting in two hosting companies giving us a warning. All our development time is now diverted this week to fix this problem. Fortunately, this has created another (1) and (4) opportunity for us.
4. We cannot compete with the likes of Scribd ($13 million investment) and Docstoc ($4 million investment), but can carve our own niche. Hence focusing on the enterprise and the benefits we can bring instead of focusing on consumer markets, such as taking Amazon.com head on with book sales.

If you are planning for your first tech startup this festive reason, think about how quickly you can get to market, and the four points I raised in here. If you a startup veteran, please share your experience.

For first timers: I am comparing my experience against Marc Benioff who founded Salesforce.com and grew it to be the first $1 billion revenue SaaS company.

Previous posts:
Forthcoming knowledge share blog posts against Marc Benioff

Published inedocr.com
  • This is definitely an interesting topic, thanks for sharing and opening up for discussion.

    I certainly can't agree with “do it fast, simple, and right the first time”. One thing I've learned as I've been working on OnePage is that you really should be relating everything to improving important metrics. If you're pre-revenue, then that's probably growth or finding a fit in the market (perhaps user retention). Otherwise it's probably mostly revenue.

    I think one of the best things you can do is ensure you're flexible enough to try new ideas very cheaply. Luckily for startups, being small should mean flexibility. This includes being able to split-test without it being a burden, and to split-test and measure the macro level metric to determine an improvement in the key metric. In the spirit of the Lean Startup, instead of “Build it and they will come”, “Build, Measure, Learn til they come” 🙂

    Combining this with the idea of the Minimum Viable Product, I would argue that you can determine what to build based on what will give you the best return. Of the new areas you're working on, could you not create the initial interface for one of the features without actually creating the full feature, and then show half of your users the version with the new feature available, and half the version without? Then measure the effect and determine whether to fully build the new feature. This obviously can be difficult with features which you charge for, but those which you do not can certainly be tested this way.

    Another interesting point is that of avoiding letting your users guide where you take your startup. Sure, it's great to listen to all your users, but we always try to ensure the feature requested by a user is both useful for users and also inline with our vision for OnePage before we decide to start developing it. It's great to ensure that each feature builds on getting users to pay, but not necessarily if the aim of the feature is for growth. I guess what I'm saying is it's important to decide the purpose of the feature.

    I'm definitely with you on finding the 80/20 and I think that's one of the difficult jobs startup founders are tasked with.

    As a side note, we're currently undergoing a redevelopment and I do often wonder whether refactoring would have been the preferred route. I think with startups, smallest steps as possible are the best, and getting the product in front of users as frequently as possible. Months of development without users seeing any of it is certainly a bad thing.

    “Right for the first time” implies there is only one time. But does product development ever actually end?

  • ManojRanaweera

    Joel, great input from a startup CTO. Bit of advise: don't get bogged down with metrics at this early stage. You may not necessarily have access to sizeable audience! And your audience will change as your product evolve. Those who love your product at early stages may not be there when it evolve to a full product. The optimum output might be a balance between gut feel and metrics.

    Right for the first time, perhaps imply it does what it meant to do! It does not mean the product is finished. SaaS/Internet apps are continually evolving whereas licensed software had product finishes and then patches.

    Great to get your perspective. We ought to do more tests as per your suggestions. Reality is we never ever do these type of metrics testing! The only time we tried (Google Web Optimizer) it broke the front-end. I think it was a bad implementation at our end. But usability is something we need to spend more time on in 2010, so will definitely revisit metrics

  • Cheers for the reply Manoj, I think you're spot on with ensuring it's a balance between gut feel and metrics.

    You might want to look into KISSmetrics (I'm on their beta and it is very good), and MixPanel as alternatives or additions to using Google Web Optimizer. Also, I'm implementing goals in Google Analytics right now and it sounds like a similar issue I came across with regards to breaking the front-end. Google normally want you to have two completely separate versions of the same page to measure analytics, or have separate pages for steps in a funnel where you might actually have a page with the same address but dynamically generated steps. There is a way around this, and I'm implementing it right now. If you'd like me to chat to your tech guys about the way to do this then the offer is there 🙂

  • Martin Eley

    “Right for the first time, perhaps imply it does what it meant to do! It does not mean the product is finished. SaaS/Internet apps are continually evolving whereas licensed software had product finishes and then patches.”

    A SCRUM approach supports this principle perfectly, I wouldn't get too bogged down defining detailed requirements but work from a list of features and ideas prioritising each one. As priorities change features, ideas and bug fixes can be added and removed from release schedules.