Consumer insights are more important than real-time behavior data

July 27, 2012 by Leave a Comment

When I started my career in manufacturing at Procter & Gamble 20 years ago, I experienced an impactful training simulation that still guides me today. We had a group of about 50 new hires going through orientation and we were split in to several teams all tasked with producing various colors and shapes of Play-Doh using the Play-Doh fun factory.

Each team was tasked to produce different colors/shapes each quarter and then sold their output to “buyers” sitting at a table (simulating retail buyers like Wal-Mart or Safeway) for different prices based on what was popular this quarter. The more you were able to produce and sell of the most in demand color/shape combination the more money you made. Most teams spent their time optimizing their operational strategy for the start of the next quarter; lining up different colors of Play-Doh waiting to learn which shape that they would start to pump when they heard what was in vogue from the buyers.  Many teams made about the same money. But the key to winning the simulation was recognizing that there was a training facilitator who represented ‘the consumer’.  If a team just went and asked ‘the consumer’, they would share what shape/color combination would be popular in the upcoming quarter or two. The more you knew about what the consumer was going to buy the more you could plan ahead of time and prepare lots of inventory to be sold right at the start of the quarter.

This simulation left a career-long lasting impression on me – consumer insights can give you the ‘keys to the kingdom’.

In today’s connected world there are many powerful measurement tools that let you know exactly how users behave when interacting with your product.  Our company uses KISSMetrics, Optimizely, Facebook Insights, Google Analytics, SendGrid, MailChimp and of course our own home-made tools to analyze server and user data. These real-time applications are either free or near-free.  It is remarkable how just about every detail we could want to know is now available in real-time.

But despite this incredible toolkit to understand user behavior, none of them provide the user insights that will be the core to the success of a product.  The data captured from them enables are necessary but not sufficient to make you a great product innovator. Let me explain. You can spend all your time building something you think users will want and then watch every detail about their behaviors. You can then optimize your product to improve performance by some impressive number. But if you are working off a small base an improvement of 100% or 200% really doesn’t mean anything. You are just getting to the top of a small hill (or in mathematical terms, you’re finding a local maxima).

Consumer/user insights are what allow you to identify where the big mountains are. This is where deep functional product management and marketing skills are necessary.  Being a quant jock is great for building applications in which most of the work is done under the hood (like search or online retail), but building a consumer application with interactive workflows requires knowledge of core product/marketing know-how. Best practices in iterative user design, focus groups, follow-me-homes, online surveys and usability testing are all part of the recipe to help find where the big mountains are.

I continue to be amazed at the power of today’s online tools and how much the world has changed in just the last five years in what they can do. However, as good as they are, they can’t replace the fundamental product/marketing skills needed to discover that incredible insight which will give you the ‘keys to the kingdom’.

Filed under Consumer, Insight, Market Research, Product Development

Startup challenges and how they can differ from large companies: Focus

March 28, 2012 by Leave a Comment

As someone who has spent about half my career in startups and the other half in large organizations, I constantly compare one to the other as a way to figure out how to get the best of both worlds.  There are many examples (and sterotypes) about how big companies are notoriously slow and lack innovation.  Just about anyone who has worked in both types of businesses can put together a big list of pros and cons of big versus small.

The questions that I continually ask my network of former large organization leaders who now work at startups typically relate to the common challenges startups face and what could they learn from large organizations.

This post is the first in a series stemming from recurring observations and conversations I have had across many startups in which benchmarking successful large companies practices would benefit a growing startup.

To start we will discuss ‘Focus’.

There are many smart people who have already discussed the importance of focus to any organization.  Just about every organization says they are focused, and even believe it. However as you start to peel the onion and ask specific questions, you can see how startups try to be clever in investing in too many opportunities at the same time.  To me, in a startup there are two elements to being focused. The first is having the right amount of time, people and resources to successfully achieve a project’s goals. But the second is also not investing in additional projects that could draw on resources, cash or leadership attention that your main project could have/would have needed.

The first question I like to understand about a startup is where they are at as a company. Are they before or after product-market fit?  When I worked at Emmperative we had two big customers who wanted very different enterprise marketing solutions.  Coca-Cola wanted a Sales & Marketing digital asset management distribution solution while Procter & Gamble wanted a Brand Management workflow product. Let me tell you, these are very different types of products. But we wanted to keep both name-plate companies happy. So we split our engineering efforts to solve two separate jobs.  Without going into all the details, our products were still so young they didn’t solve either customers needs completely.

At Adify, we hadn’t yet gotten to product-market fit with our first Build-Your-Own-Network solution, yet we were going after four completely different markets trying to see where we could get traction. Of course each of the markets had their own unique requirements, so until they began to focus on just one market segment which showed promise a lot of cash and resources were spent inefficiently.

One way to think about focus is to divide a startup’s offerings into the three buckets.

#1      Growing & profitable

#2      Fast growing, but not yet profitable (after Product-Market fit)

#3      Before Product-Market fit

If your startup is far enough along to have a product line in bucket #1, it really makes sense to keep investing in your success and allocating resources to buckets #2 and #3 (we can discuss the proportion at another time).

However most early stage startup’s primary/flagship offering is in bucket #2 or #3.

Let’s tackle the easy case first, bucket #3. If your startup has not yet reach product-market fit with its primary offering, investing in multiple offerings or customer segements will be a challenge as you dilute your focus. Even if it the same platform but targeting different markets, this will be a distraction to your team and scarce resources. Now, this doesn’t imply doing market research to seeing how close an offering could meet a different market segment’s need. Or going on a sales call to a potential customer in a different category. I am referring more to building market-segment specific capabilities into your offering that would ‘enable’ you to sell to two different customer types at the same time.  This is where not being focused comes into play.

Now let’s discuss the more common situation. Where a company’s main offering(s) are in bucket #2 and yet they also are investing in new offerings in bucket #3. (And to be clear, in this case I am not talking about a bucket #3 product which is a next-generation version of a product in bucket #2. In fact I would consider that investment as part of bucket #2.)   I am talking about where a company has a fast growing product that still hasn’t reached scale or profitability (bucket #2), and yet the company is investing significantly in new markets, customer segments or products (with or without the same technology platform)  (bucket #3).

There is a company I know who has a phenomenal offering in market that is growing quickly, but has not yet reached scale or profitability.  Thanks to that main product line’s success (with product-market fit) the company has been able to raise lots of cash. With this new cash influx, the company has invested 20%- 50% of its monthly cash burn into new products/markets that leverage the existing technology platform (bucket #3).

Here are some of the issues facing the company:

–          The main product line is struggling to get to scale and profitability.  The company has been able to find a market for their product and sell it, however the commercialization and operational efficiency required to get to scale has yet to occur.  Management experience and organizational focus on these two areas are seen as the primary reasons.

–          As the company struggles to get to profitability with their main product line, the investments in the early stage product development (bucket #3) has siphoned talent, resources and cash from the company.  Their balance sheet looks weak and these new products will still require a huge investment to get to product-market fit.  This has put the company in a challenging position to consider raising more cash that they really shouldn’t need if they were more focused.

–          Given the lack of ability to commercialize and scale the primary offering, there is a lack of organizational confidence that even if the new offerings find product-market fit that the company will be able to scale them too.

The challenges this company faces are pretty big. There are many challenges the leadership needs to address and they need to do it quickly before their cash position creates problems. Their situation is a wonderful example how the leadership did not did not make thoughtful decisions on how to keep the organization focused in a manner which struck the right balance of short term delivery of results and long term growth.

While I don’t know the right amount of resources to allocate to non-primary Bucket #3 opportunities for a early stage startup, I am sure the maximum number is less than 20% and probably more around 10%.

Larger companies with profitable product can (and should ) invest in high growth opportunities. Due to their size they can take a more portfolio management approach to their investments and balance short vs. long term growth in way that fits their ability to generate cash from their core businesses.

If you are in an early stage startup, you should ask yourself how much of the company time, people and resources are we dedicating to these Bucket # 3 (before product-market fit) opportunities? And how much is it ‘costing’ to pursue them in terms of cash, resources and management focus.

Filed under Product Development, Risk, Startup, Strategy, Team

Audi or Honda? Striking the Design vs. Development Balance

February 29, 2012 by Leave a Comment

Last year I bought my first non-Japanese car in over 20 years of car ownership. I purchased a pre-owned Audi A6 from a friend of mine.  It is a wonderfully designed car for the driver with a great interface and   powerful engine.  Quite frankly it is a little too fancy and stylish for my personality, but my wife and kids love it.

A few months after driving the Audi I had to take it in for an oil change. To my surprise, instead of it being the usual $40 plus a free car wash in about 15 minutes, it cost over $100 and took almost an hour. I asked the service person why it was so expensive, and he explained it was partly due to the higher grade synthetic oil required, but mostly because of the time required to remove several components under the hood just to get to the oil tank and drain it. He told me that it takes almost 15 minutes for this preliminary step before they even start the oil change. When done, they need to reassemble all the parts again and it takes another 15 minutes to complete. I was so surprised at how two different makes of cars could have such dramatically different maintenance costs and times for basically the same operation.  When I took in the Audi for its scheduled maintenance session a couple of months ago the same themes reappeared.  The Audi dealership told me they would charge me $300 just to tell me why a dashboard indicator light was on. It took longer and cost more for the Audi check-up compared to similar work on my other car, a Honda.

This experience got me thinking about the choice car manufacturers make when designing and developing their automobiles. Forgetting the different class of car for a moment, it seems clear to me that Audi optimizes for an awesome user experience, but there is a trade-off, the cost of maintenance is much harder for those tasked with keeping the Audi running lean and mean.  In contrast, Honda strikes a balance differently, clearly making some compromises on the user experience but makes the total cost of ownership much lower, giving them a more broad appeal.

Do you think these kinds of choices only apply to cars? Well if you have owned an iPod or iPhone for a while you may have had the not-so-wonderful experience of the battery dying. It is almost impossible to change the battery on your own. Instead it is a long and expensive process to get it repaired or replaced relative to just buying a new one at Best Buy or Amazon and popping it in yourself.

So how does this relate to a technology startup?

Product Design is all the rage these days and clearly user’s expectations of a great experience is going up. But as a small startup with limited resources there are many time when you need to make choices about what and how you build your product.  Thus the question I am asking is should you build an Audi or a Honda?

At the early stage of your company when you are just trying to get to product-market fit, it is more important to make sure you solve an unmet need of your target user with a product that can easily be improved and scaled rather than ensuring an absolutely amazing end-to-end user experience.  Here are some examples of when you are making these choices, knowingly or unknowingly.

Design:

In an ideal situation every pixel on a screen is beautifully designed with cool interaction widgets and impeccable graphics and colors. Several applications make wonderful use of animation and detailed graphics that bring a certain ‘wow’ factor to their users. However, each element takes time and money.   I have several creative ideas for Jernel that will certainly delight users in their initial and ongoing use of the product, but at this time when we are still trying to make sure we solved the right problems in the right way. Now is not the time for us to be investing time and resources into these cosmetic elements. We’re still focused on the ‘steak’, when we solve product-market fit, we can put more effort into some more ‘sizzle’.

Focused Components vs. Multi-Functional Systems:

As mentioned in the Audi oil change example, Audi is optimizing for the user experience not the mechanics that will be performing maintenance on the car. So making changes and updates takes longer and costs more.  Audi has taken individual components and combined them into multi-functional systems. So when one component requires attention the entire system must be taken apart and reassembled.  Software code can also be written in very small modular, bite sized code that has logical break which is easily tweaked as you scale and adjust your offering.  This provides meaningful division between critical components and keeps them properly separated within the different layers of the application.  All this allows for easier maintenance, scalability, reliability and performance. However, all too often I have seen engineers hack several components together in order to get them to work for a release. If something needs to be changed at a later date significant surgery needs to be performed to address many shortcuts that were taken to quickly get a release out the door and unnecessary mixing of different tasks into a single, bloated chunk of code.

Simple Maintenance – Leverage Existing Tools vs. Building Everything Yourself

With all the open source tools out there, it is really worth taking the time to investigate what is already available to re-use for you needs. Almost always they will not be a perfect fit, but good enough.  The key is that there these open source resources are constantly improving over time and leverage those benefits as your product grows up.  An example of this trade-off for us has been using our own unique buttons in our application. We have over unique 100 buttons in buttons in our application, many times requiring different colors depending on the user context. While it is not expensive to have each button wonderfully designed to look great, it can be a challenge to maintain all these assets as the product grows the way we hope and expect.  Instead, we have moved to using CSS3 HTML standards as a way to simplify our lives and have one less item to worry about maintaining as the product evolves and expands over time. The buttons may not be as pretty, but it sure simplifies the lives of several product folks charged with managing the buttons.

Not every startup can afford to have a Pixar animation engineer or an Apple designer on their team, so the reality is that you will probably have to make choices early in your product development about how sexy your product will be.  No doubt with the right people and resources you can indeed create an elegant user experience, but first solving an important user need and striking the balance amongst your limited resources is critical. With the right team and a little luck you could build an Acura in your first releases as you search for product-market fit.

Filed under Product Development Tagged with , , , ,

Pricing: Capturing As Much of the Value That You Create As You Can

September 1, 2011 by Leave a Comment

I’ve wanted to write about pricing for a long time. Finally, I have put together my first piece on a practical framework I’ve seen in action during my career. Pricing is one of the most important and hardest strategies to develop. It goes without saying that a product or company’s revenue is directly a function of their pricing model. Pricing is what drives revenue, margins and profitability.

I am not an economist and do not claim to be an expert in micro-economics, even though I am familiar with most of the basic concepts. In this blog you will not see me recommend that you set your price at the point where marginal revenue = marginal costs. In the world of internet software where marginal cost is usually negligible that concept is somewhat meaningless. Instead…

Pricing is all about capturing the value you create for a customer.

Let me explain the three core concept in more detail: creating value, capturing value and price.

Creating Value:

By definition if you have created a product or service that people are willing to pay for there is some value that you have created which is greater than your customer’s current state without it.  Somehow the offering you have put together is better for your customer than doing nothing or trying to do it themselves.  A few obvious examples are buying a ready-made cake at the bakery instead of baking it yourself.  It may be cheaper to buy all the ingredients yourself and bake it, but it you may not have time or be willing to risk having the cake not turning out as well as the store-bought one. Thus the value created by the bakery is greater than the value of the cake you would make yourself. Net, net it is some combination of costs reduced and/or benefits created that determine the value of an offering to a customer (relative to their current state or substitute option).

We will talk a little more about this later, and without getting into too much micro-economics, the value created by an offering isn’t the same for every customer. This is basically what people refer to as the demand curve. At different prices more or less people will want to buy your product.

Capturing Value

This is one of the most important (and sometimes ‘hidden’) elements of pricing. The essence of which is, given that you create real value for customers (save money, make money, other valued benefits that are delivered) is how can you capture as much of that value that you create for customers?  Is there a way to tie the price your charge to the value created for your customer? This may sound obvious and easy, but it isn’t. This is especially true if there is a big range of value created for different customers for the same product. A great example of this is Microsoft’s Excel. The value to a college student using Excel to do homework assignments etc. at school are very different compared to a management consultant building a sophisticated M&A model – yet the price is essentially the same for the two different types of customers (ignoring the small price difference between MSFT business vs. school edition of Excel).

Furthermore, a concept I like to refer to as ‘metering’ is how a product ties its price to the value it creates for customers. An easy example of this is buying a box of cereal. The metering device is the physical box that the cereal comes in that sits on the shelves at a grocery. There are usually several sizes at different price points based on the volume that you are buying. Another historically great example of metering to capture value has been the phone company. They were able to charge for long distance telephone calls where the phone company metering device was based on both the duration of the phone (i.e. number of minutes) and the distance between the callers. The phone is one of the greatest inventions but without having metering devices built in, the phone companies may not have been able to generate as much revenue. (Of course the world has change thanks to VOIP technology so this example is not as black and white as it used to be thanks to All-You-Can-Eat pricing, Vonage and Skype).  I will touch a little more on this later, but building in pricing-related metering devices to capture value is a critical investment for a technology company.

Price

I am sure this is a gross over-simplification of different pricing strategies, but in my real-life experience in consumer products, enterprise and online software there are basically four ways to look at price.

They are:

  1. Pricing relative to costs
  2. Pricing relative to competition
  3. Pricing relative to value
  4. Psychological pricing

I won’t spend much time on 4. Psychological pricing which entails things like fashion and status related items or specific price points like $9.99 for a book or $0.99 for an iTunes song.  These are special pricing types and I am sure there are other sources of well-research experts who can explain these less tangible and sometimes more tactical price points. Instead I will focus on the first three.

Other elements I won’t touch on here are price optimization, which to me has more to do with price elasticity (to be covered an upcoming blog) and bundling. These two concepts are ‘click down’ components that get deeper into the mechanics of your pricing strategy once you have your basic principles figure out.

1. Pricing relative to costs

This is pretty much what it sounds like – you figure out what your costs are and the determine the margin that you would like to achieve. In many industries there are standard margin expectations. Not sure how these have held up over time, but the rules of thumb I have used historically were professional services at 50%, retail food/CPG 30%,  restaurants 60%. I am sure I am over-generalizing, but this type of pricing easily applies to when your customer can easily do the math on how much it would cost to find an equivalent solution to yours on their own.  Since it usually isn’t worth the effort for them to build vs. buy they will choose to buy yours solution if the margin premium you are charging is reasonable. Pricing relative cost is also frequently used in commodity-like markets where there are many suppliers offering a very similar, mostly undifferentiated solution compared to yours.

2. Pricing relative to competition

The basic premise of pricing relative to competition is looking at direct competitors and substitute products for yours. For example, if something breaks in your TV or game console and you go to a repair shop to get it fixed you will compare how much they will charge you to buying a new one (all else being equal).  When I worked at Kraft I was involved in launching a new dessert product and we compare equal servings of bakery desserts, versus packaged desserts versus from-scratch to get the spectrum of competitive prices to see where we would fit in.

Another example is video games. For simplicity sake let’s say Madden Football or Call of Duty costs $50, most buyers will ask themselves will I spend at least 10 -15 hours playing this game?  Why? Well because they are probably comparing the entertainment value of the game versus going to watch a movie in a theater. Assuming each movie cost about $10 and lasts a couple of hours, it is pretty easy to do the math on whether or not you think the video game is worth about as much as five movies.

The less differentiated your solution is compared to alternate solutions the more you will end up with this type of pricing strategy.

3. Pricing relative to value

As discussed earlier, this is the case where you try to capture as much of the value (cost reduction and/or benefits created) that you deliver to customers. At Emmperative we tried to price our software based on the value we created. As an enterprise software company our primary value proposition was all about increasing time to market with higher quality for our customers along with some cost savings along the way.  One of the challenges was selling the fuzzy revenue benefits to our pricing as customers focused on the cost savings as a way to pay for our software. In hindsight the primary challenge I think we faced is that we tried to price the software as too high a percentage of the value we were creating. Over the past 10 years I have developed a rule of thumb that you should expect to capture 10%-15% of the value you create for your customer. This way they should easily see that buying your solution will provide an order of magnitude improvement over the current state.  Of course early on you could easily charge a higher percentage due to your first-to-market position, but in the longer run the 10% rule-of-thumb is pretty helpful is assessing the potential for a technology business.

One of the best models in the history of pricing relative to value is Google AdWords. When Google AdWords (and AdSense) achieved scale/network effects their auction-based pricing per click of keywords allowed them to capture almost the entire amount of value their ad/search system created for advertisers. Since most sophisticated advertisers work with some type of Cost-Per-Action the advertiser can easily do the math to figure out the value of each click and bid up to that amount and be happy paying it.  As a result, Google has a near perfect system to capture the value they create all along the demand curve by having different keyword pricing for each advertiser based on what they are willing to pay.  Without scale and network effects that Google has other ad network solutions can’t capture anywhere near the same value as Google does.

Picking the attributes to meter

Sometimes you have the ability to have a very dynamic and flexible price metering capability like auction-style model of Google Adwords or eBay.  But many times you will need to pick specific price points.  Many broad-appeal technology based solutions have a feature based two or three tiered pricing Basic/Premium or Good/Better/Best (as I saw at Intuit with their QuickBooks and TurboTax products) (note: QuickBooks is a great example where the value of QuickBooks for many customers is more than 10X what they would pay relative alternate solutions like an accountant’s hourly rate). This type of pricing basically segments the market into different user types or levels/types of functionality and prices accordingly (and may include a free version a la “freemium model”).  However there are other ways to price beyond feature breadth and depth.  Subscription pricing is usually time-based, enterprise solutions can be based on number of users, and others like Dropbox are based on storage capacity.  Understanding the different types of customers, their segmentation based on usage and profile and what they value is the key to picking which attributes to meter.

Building the metering capability into your product

It’s great that the phone company was able to allow anyone to call anyone else; a phenomenal innovation back in the day. However, the ability to measure the duration of a call and the distance between the callers was just as critical to their success as the actual phone call.  I am sure a large amount of resources went into building these metering measurement and billing systems – maybe even as much effort as rolling out the telephony technology? The point being with all new ways to deliver web-based solutions these days, the effort required to build pricing-related capabilities can be a significant investment. The earlier you include this into your development plans the higher the probability of you maximizing your value-capture.

Putting it all together

Figuring out the attributes you are going use to meter the value delivered to customers and charge for early on is critical to the success of your offering/company.  The earlier you build the metering (and measurement) plumbing into your offering relative to the value you create, the better your likelihood of being able to maximize your revenue potential. My experience has been that putting in the metering and measurement tools take almost as much effort to build into your product as the core functionality of the product. So if you solely focus on building the customer solution you may unknowingly be making major compromises to your revenue potential if you need to retrofit your solution or find a less optimal metering tool to charge with down the road.

Filed under Margins, Pricing, Product Development, Strategy, Value

Building a great product in a weekend – is it possible?

August 16, 2011 by Leave a Comment

So I’ve been thinking a lot about advice I have seen on Twitter about getting your product out there super-fast. In particular, I have pondered about the statements that encourage entrepreneurs to build a product in a weekend, launch it, get feedback, iterate and, if you can, charge money for it; all within a few days.

What I’ve been struggling with is:

Is that reasonable? Could we have done that?

Even more so, what kind of traction is reasonable to expect?

How long would it take to demonstrate enough traction to raise an institutional (VC) round from such a fast time to market?

As an early stage entrepreneur we hear a lot about finding the Product/Market fit. Which basically means figuring out if you have solved a problem with your offering that a significant number of people have.  The way I describe it is ‘do we have a winner?’ i.e. is this a winning, big idea concept if we keep going with it?

However, finding Product/Market fit and have a mass-market appeal product are different. You can probably figure out if you have Product/Market fit with Innovators as well-described in the Diffusion of Innovation Graphic:

Diffusion of Innovation

And this is a tremendous milestone in itself, because it is very hard to get product/market fit with any sized market. But then there is the next major milestone which I call 80% product/market fit.

To me, 80% Product/Market fit means that the significant majority of users in your target market can use your offering successfully. In other words it solve the jobs they do in order to want to continue using your product again (and again). This does not mean having certain advanced features that leading edge / pro users want, but solving the problems the vast majority will need in order to adopt your product on a regular basis.

80% Product/market fit from a time perspective can occur somewhere between the latter portion of ‘Early adopters’ and the early ‘Early Marjority’. Why isn’t it a specific milestone on the graphic? Well because I am separating the product development cycle from the customer acquisition and distribution aspects of technology adoption. The graphic shows when users actually adopt the product. The product may be ready for the vast majority at times different from when users actually start using them due to the  acquisition capability of the organization (sales force, channel management, social media etc.).

There is a wide spectrum of what it takes to get to Product/Market fit at the 80% level. While by no means simple, it is pretty fair to say that the timeline varies by the types of offering you are developing. Some very successful products like Instagram, Twitter, eBay, Turntable.fm surely had a much shorter time-to-market compared to complex applications like most EA titles, enterprise software, ad serving technology and popular analytical tools like Google Analytics.  An interesting observation is that many of the companies that have had shorter development timelines seemed to have large amounts of user generated content and participate in markets with network effects.

There are some companies like SAP which started in 1972 and took years to build to solve enough problems (aka ‘jobs’) to become an option for large corporations in the early 90’s with R/3. Most of Microsoft’s products took several iterations to find 80%Product/Market fit.  The period between MVP launch and 80% Product/Market fit could easily be measured in years (decades?).

Why I am writing this post? Well, we certainly could have been in market several months sooner if we just built what we released as our MVP.  As you might recall, after building several workflows, we removed a large amount of functionality for our public release with the expectation that most will be added back in at a later time.  However if we just built the MVP to start I don’t think we would have gotten our Product/Market fit to the 80% level much faster. In fact, we may have slowed it down.

Let me explain…

Because we were designing and building a product that was striving for the 80%, we made several architecture and infrastructure choices and investments that we would not have anticipated upfront had we just been building our MVP.  So while we may have gotten some early traction with Innovators and very early adopters, it may have taken us longer to get to the 80% level by having to re-architect various aspects of our product at a later date (see my post The Biggest Decision). John’s perpective on this is almost always ‘better to do it now while the patient is open’, and after four plus years of working together he is usually right.  Of course, it was very possible we made some investments in areas that turned out to not being needed or important so that may have worked against us. We also missed some feedback that we should have gotten sooner (Launch & Learn – quickly adapting to insights from our users), luckily that wasn’t too costly. However, on balance we feel confident we will move faster once in market to quickly get to 80%.

Since traction is so important, our speed to 80% product/market fit is what we are solving for; so that we get hundreds of thousands of users not dozens or hundreds of Innovators or Early Adopters. If we got the right initial product/market fit then our speed will be the key to our success.

If someone else has a new product that can be built in a weekend and get 80% product/market fit right away (and ideally benefit from network effects) that is awesome, and I commend them with coming up with such a great idea and opportunity. However, those opportunities are rare. I think the significant majority of meaningful companies require several months to get to 80% product/market fit and in many cases even longer.

Filed under Product Development, Startup Tagged with , , ,

Getting the right people in the right seats on the bus

August 2, 2011 by Leave a Comment

One of the biggest challenges in an early stage startup is to have enough talent on the team to do all the tasks required to get stuff done right.  If you only have a handful of people in your company (i.e. four or less) it is almost impossible to have all the skills needed to deliver a new offering, especially if it is some type of consumer application like ours.  So how do you find all the people to do all the work that is needed?

For many years now I have talked to people I work with about people I would label ‘Swiss Army Knives’ and others who I would call functional experts.  Swiss Army Knives are basically like the metaphor suggests, they are talented individuals who can perform multiple types of tasks well enough to accomplish the required objectives. This does not mean that they are experts in any specific functional area, but in a startup environment they are able to figure out what is needed and to make it happen. Almost always Swiss Army Knives are choosing this breadth vs. depth capabilities. My experience is that they are very smart and flexible individuals and if they chose to go deep in any specific functional area (and usually they have at least one or two in which they have gone deep) they would be world class in that area.  I started my career at Procter & Gamble and they really encourage attracting and developing Swiss Army Knives, and a lot has to do with their philosophy of promotion from within, general management skills and an upward spiral career path.  Which basically means that at P&G high performing employees are encouraged to take multiple cross-functional roles during their career as they move up the ladder. Being able to perform well in multiple functions and appreciate different functional roles is a critical leadership and career skill.

A few additional thoughts on Swiss Army Knives, while I don’t have statistical data on this I have found that only a small percentage of people fit this categorization, even in great organizations. What’s even more interesting is that I have found that SAKs tend to find each other and hang out together. I really don’t know why, but it just seems that they tend to have similar values, experiences and outlooks. Also, not being a SAK is not a bad thing either, having deep functional expertise is necessary in almost every company especially when combined with the depth of experience that the SAK will almost never have.

So how does this relate back to driving a successful startup?  Well, if you are small and can only have a few folks working full time in your company I would suggest having as many of your early employees being Swiss Army Knives as possible. By having as many people on your team who are able to get things done (in a ‘good enough fashion) within your team means that you do not have to tap outsiders (contractors, consultants, agencies etc.) to help you get them done.  Kind of obvious, but it all start with who do you have riding on your startup bus.

My partner John is a Swiss Army Knife. Not only can he tackle just about every technical aspect of our product (such as architecture, web service integration, functional coding, presentation layer functionality, HTML/CSS, dB management, operations etc.) he also has a unique appreciation of consumers and marketing from his past experiences. Thus when we discuss new features or user feedback we can immediately have a great, productive discussion about what to build and translate the conversation into new requirements.

However as you grow your startup you can’t do everything yourself and you can’t hire full-time people for every role that need to be done. There are lots of ways to address this issue via contractors, interns, consultants etc.  What we have found to work pretty well for us is using oDesk (www.odesk.com).  We use oDesk for both product development and marketing-related experts. oDesk is a great resource if you use it properly but it is certainly not a silver bullet. In fact, our experience is that unless you put a very big effort upfront into hiring and managing the functional experts you find you will be very disappointed in the results. Leading a team on oDesk takes as much effort if not more effort to coordinate (to account for time zone, language and not being in the same room).  In fact until we developed the right process and tools for the team, it was hard for some oDesk people to succeed was a challenge for them. But as we have found if you get your ducks in a row and find the one or two key people that ‘get it’ and can ‘do it’ the bang that you get for your buck compared to hiring locally really pays off.

To-date, getting the right people in the right seats on the bus has been a long, iterative challenge with our efforts finally paying off. We are happy where we are today, but of course it is a never-ending battle as we try to grow and keep up with all the new changes to our product and small company.

Good luck to you on getting the right people on the right seats on the bus – and may as many of them be Swiss Army Knives as possible.

Filed under Hiring, Product Development, Startup, Team Tagged with , , ,

Launch & Learn – quickly adapting to insights from our users

July 28, 2011 by Leave a Comment

Well the last month has certainly been very interesting. We launched a Private Beta version of Jernel to a few select folks including a couple of friends who are product design and usability folks. I also set up shop in a couple of Starbucks and did some usability testing with random users in San Francisco and Las Vegas.  It’s amazing how quickly we got consistent feedback from everyone who tried Jernel out.

First the good news, everyone loves the Jernel concept of it being a fun, easy way to share and remember your life experiences.  Then, when we tell them that Jernel also allows you to add on specific Jernels for different life events or hobbies I immediately get their request for some specific type of Jernel that suits their world. Then they send me their email to sign up to be a beta tester. This is awesome, we really couldn’t ask for a better qualitative response.

On the other hand we got very direct and actionable feedback in two key areas:

To start, as easy as our product is to use (as demonstrated by our task completion rate and user confidence) it was still not easy enough. We realized that we still had a gap between ‘Easy’ and ‘Drop Dead Simple’. Thanks to some excellent, actionable recommendations by my design friends and being able to quickly get feedback to the new wireframes with real users we made the decision to make a major UI change to how Jernel entries are added and displayed.  Thanks to the latest jQuery tools and other fancy Javascript capabilities we’ve been able to simplify the Jernel entry process to just a couple of clicks. Luckily these changes are mostly cosmetic at the presentation layer and do not require many changes to the core functionality and as a result we’ve been able to make the changes in just a few short weeks.

The second major theme we heard was all about branding and graphic appeal.  We started from a place where we were making everything customized – each type of Jernel, badges, buttons etc. And while they were generally consistent, they didn’t really have a broad enough appeal or we created user complexity by offering too much choice. So we took that feedback to heart and have tried to solve for the ‘highest common denominator’ in our branding and graphical design. We have simplified our color palette, use of colors and number of badges. While I am not 100% sure that is where we want to be in the long term, to get to a public launch it really made sense to simplify right now and then expand later based on in-market learning.

Net-net, we have dramatically simplified our product for the initial Beta release. In fact, we have stripped out the majority of functionality we have built to get to market quickly and learn from our users.  While we expect to use all the stuff we removed in subsequent realeases, I am sure they won’t necessarily return in their original form but be adapted based on new insights.

The flip side to simplifying functionality and streamlining our branding/graphics within the app is that we’ve made a choice to provide less capabilities and options to our users.  I am expecting us to hear that we over-simplified things and that users will demand more if they are going to make Jernel a regular part of their life.  I am looking forward to that moment because we are ready for it.

Filed under Product Development, Strategy

The Biggest Decision

June 2, 2011 by Leave a Comment

So we have been working  on Jernel with our small team since about November. It is now June. We thought v1 would have been completed by March and in reality it won’t be ready until at least next week – so essentially about 3 months behind what we expected. Like most startups we have been trying to deliver a Minimum Viable Product (MVP) for v1 (a la Lean Startup philosophy). The reality is that we are delivering a lot more than an MVP. This has to do with a decision we made a long time ago about how we would architect our product platform.

Let me take a step back and explain.

Last year we had a working model of the Jernel offering and did some user testing which taught us a lot. Not only did we get a feel for what users valued and what they didn’t, we also got a pretty good qualitative feel for the appeal of Jernel. Now past experience has taught us not to overvalue user feedback in usability testing on how well a product will do, but this time was a little different because the sentiment was nearly unanimous and consistent. It has been the same since I have told or shown anyone about Jernel and how it works. I am sure many marketing purists will tell me I should not overweight this feedback – but at this point in time (before we do our next set of user research) I still believe we have something special in development.

After we did the user research I also went to visit a few friends on Sand Hill road just to share with them what we were doing, get their feedback and start having them track our progress. By far the best piece of feedback we received was from a young VC partners at a major firm who suggested we horizontalize our offering and create add-in vertical solutions. This meant that instead of having unique offerings for each vertical to allow users to have a general version of our app and add ‘action packs’ as he called them for each area of interest to the user. “Otherwise you idea seems to narrow” he said. Several other good points were made that I hope to include in future posts.

The main benefit to creating a single product platform would be the ability to only need to acquire customers once and then retain them for life while they Jernel about all their interests in single location. This made a lot of sense given our learning from our first offering.

However, this feedback meant we would need to fundamentally change how we architected the product. Instead of separate instances of each vertical we needed to have a single platform with users would customize by adding the individual verticals that were right for them. This meant the set-up process was to be more complicated and user experiences needed to be adapted to toggle between verticals. It would also mean changing the paradigm the user would need to understand how the product worked. Net-net this added complexity and time to our development.
Now that we have an almost-ready for primetime product it is clear the decision to have a horizontal platform with vertical solution was the most important and best decision we have made so far for Jernel. Without making that choice it is likely we would have created our “start-up ceiling”, limiting our potential before we even started.

Filed under Product Development, Strategy Tagged with , , ,