Category: Product

Startup User Growth Priorities and My Attempt at Illustrating them Using Javascript

I was recently thinking about priorities for obtaining new users for a web application, and – since I’ve gotten pretty far in Codecademy‘s Code Year – I figured I would try to illustrate my thoughts using Javascript conditionals:

Screen Shot 2013-02-02 at 4.59.42 PM

Disclaimer: Obviously the code above wouldn’t be very useful as code, but it was a good exercise in thinking about hierarchies.

In plain English, the above code is an attempt to illustrate the following hierarchy:

1. Create an awesome product

Your number one user growth priority should be to create an awesome product that people will love, will use repeatedly, and will be compelled to share with their friends all on their own because they love it that much.

Granted, in the spirit of the lean startup approach, this may be a work in progress. Hopefully you have already validated or are currently validating the product’s awesomeness or future awesomeness with your customers.

IF awesomeness is (at least) being pursued…


2. Bake shareability into the product

Build something into the product that amplifies the sharing process in number one.  An easy example of this is Dropbox’s referral engine, which has at least two important prongs: 1) the free additional space you receive for inviting friends; and 2) the ability to invite a non-Dropbox user to a shared folder.

The reason baked-in shareability is subordinate to product awesomeness in this hierarchy is that the baked-in shareability only amplifies sharing that would have taken place anyway. If the product is not worth sharing in the first place, amplifying that sharing won’t do much, just like a guitar amplifier doesn’t add anything when music is not being played.

IF baked-in shareability is underway…


3. Create a structure measuring user experiences

If you’ve taken the broad steps of building an awesome product and have greased the wheels for the sharing of that product, then you will want to start zooming in on the details. Presumably, with steps 1 and 2 underway, people will start checking out and using the product. You will need a structure in place to measure everything you can about how users interact with the product, so that you can constantly make improvements to conversion and overall user experience. Do A/B testing to see what layouts and calls-to-action work best. Use analytics software to find ways to patch up any leaks in your conversion funnel.

This tactic falls where it does in the hierarchy because if users have no reason or opportunity to check out the product (i.e. if 1 and 2 are not satisfied), then improving those users’ experiences would be a fool’s errand.

IF all of the above are satisfied…

… and IF the cost-per-acquisition from paid marketing channels can be justified…

only THEN…

4. Consider paid marketing for your product and investing in PR

Without the previous three steps in place, marketing your product will be very expensive, as it will be swimming against a very strong current.  In this case, I am including investments in PR with paid marketing. (NOTE: achieving press is easier if you have an awesome product).

You’re much better off if your marketing spend is feeding additional visitors into a positive cycle where: 1) they are wowed by the product; 2) they feel compelled to share it with their friends (a $0.00 CPA); and 3) they keep coming back thanks to your understanding of their behaviors (gathered from all the testing you’ve done) and improving the product accordingly.

The above steps are not supposed to be a linear chronological timeline, but rather a hierarchy of what your priorities should be. For example, it makes sense to have an eye toward shareability and measurability from the beginning, so that it’s easy to implement them when the time is right.

In my previous startup, we hadn’t fleshed out numbers 2 and 3 before we dove into paid marketing techniques. Sure enough, our cost-per-acquisition on that marketing spend was incredibly high. So we turned off the paid marketing while we buckled down and worked on shareability and measurability. After implementing a referral engine in the site and robust analytics that could monitor what was going on, we resumed our paid marketing, and the results improved.

Lean Lesson Flashback: The Concierge MVP

The Lean Startup includes a great case study of a startup that used what Eric Ries refers to as the ‘concierge MVP’. The company envisioned a grocery delivery web and mobile application that would suggest particular groceries based on recipes, feature sale items, and allow the customer to order through this app.

Rather than invest their time and money into building even a primitive version of the web app, the team went to grocery stores, approached potential customers in person, and started to offer them the services that they envisioned the web app would eventually do. When they found someone to accept their services (for free to start), they continued providing value to the customer. Eventually, they asked the customer to pay for the service, and the customer did. The act of the customer actually paying for the service was a crucial validation of their hypothesis about the usefulness of their web app.

The concierge version of a minimum viable product requires manually taking care of initial customers with the attention that a personal concierge would provide at an upscale hotel. While the vision for your product or service probably includes more automation, this personal approach allows you to experiment and learn about the validity of your hypotheses without investing time and money in development.

Looking back on the founding of my previous startup, Bungolow, my cofounder and I definitely could have used this technique before we invested serious money and three crucial months on development of our website. The bulk of the three months of web development was spent on the calendar / booking / payment processing system on the website, which allowed a customer to select an available hotel room date from a calendar and book the room using their credit card.

Bungolow's prematurely complex calendar booking system

Above: Bungolow’s prematurely complex calendar booking system took three months to develop, when just a sentence telling customers to call us would have sufficed early on.

While the calendar booking system was always part of the long-term vision of the site, we could have launched an MVP without the complex (and costly) system in place yet. We could have spent two days – rather than three months – putting up a simple website with a phone number and a line of text: “If you are interested in our current hotel deal, simply call us, and we will personally walk you through payment and any questions you may have about the sale.”

We would have learned a ton of information about our customers and whether our product solved a problem for them. Three months and serious money later, the complex booking system was live, but it didn’t put us in a position to learn more than a concierge MVP would have.

Why a Great Hiking Trail is Like a Great Website or Web App

This post was inspired by a recent hike on one of my go-to trails: The Billy Goat Trail A along the Potomac River outside Washington, DC.

The Billy Goat Trail

A good hiking trail is like a good website or web app. In this post, I am referring to hiking trails that are designed, marked and maintained by an organization (rather than ones that form naturally from use and without a supervising organization). The fundamental similarity between a good hiking trail and a good website or web app – the similarity that drives most of the observations below – is that both strive for an excellent User Experience (UX).


Usability is one factor that falls under the umbrella of user experience, and it gets at the pragmatic ability for users to complete tasks. A big part of usability in a website or web app is the flow or navigation, and this is where the analogy with the hiking trail begins. Just as a website aims to move its users through ‘funnels’ to conversion goals using calls-to-action and navigation bars and buttons, a hiking trail has blazes marking the path for its hikers to funnel through the trail, eventually reaching the exit. However, these trail blazes must strike a balance between a) being present enough to clearly show the direction of the trail and b) not infringing on the natural beauty of the area.  To keep with the analogy, a site’s navigation details must guide users through the site efficiently but without being so obnoxious that they make for a cumbersome User Interface (UI).

As a side note, the Billy Goat Trail has excellent usability; its blue blazes can always be spotted simply by looking around, but they do not impose on the natural setting and are not on every tree or rock. Was this nice balance the result of Usability Testing by the trailblazers? Maybe.

Interface Design

The usability of a site and a hiking trail gets at the ability for users to complete tasks (i.e. purchasing a product or completing a hike), but there is more to both environments than simply roadmaps for finishing. There are visual aspects to the design that add to the UX.  On a website, this includes the layout and selection of fonts, colors, images, videos and even the copy used to provide more information.

The same goes for a hiking trail. The designers of the Billy Goat Trail could have made a straight hiking trail that stayed exactly 30 yards from the towpath of the C&O Canal – but that would be boring. Instead, the trail winds you through the forest until you reach the rocky cliffs over the Potomac River. From there, you go in and out of the woods to find amazing view after amazing view. These visuals add to your experience just as a website’s visuals add to the experience.


A website’s loading speed or its ability to handle traffic have a measurably large affect on user experience. Similarly, the speed of a hiking trail (traffic, not length) greatly affects the experience of its hikers. Being stuck behind crowds of people on the hiking trail not only makes it frustratingly slow, but it takes away from the natural beauty of the area.

For the sake of not forcing the analogy further, I’ll wrap up here. But, there are ways to continue the analogy (e.g. the error messages in a website are like the ‘Stay on Trail’ signs on a hiking trail; a sitemap is like a trail map). Ok, I promise I’ll stop now.

Photo by Vicky TGAW