By Michael Woloszynowicz

By Michael Woloszynowicz

Thursday, March 31, 2011

Infinite Scope Creep, The Sales-Development Disconnect

Let’s say you're a developer or product lead at a relatively young, bootstrapped startup. You're not yet profitable and the company's cash flows are low as your still refining your product, and have relatively few clients. To increase cash flow your sales team tries to close every deal possible and are loath to turn down any clients, even if the product is not a good fit for them. To further add fuel to the fire, nearly every deal is inked with preconditions of adding missing features that the client “absolutely must have”. Many reasons are given for closing such poor fitting deals - which I'll get into later - but regardless of the reasons, they always lead to toxic results.

The Result
The resulting effect of this disconnect is manyfold. For starters, developers begin to get frustrated as they are pulled away from the initially laid out stories in their backlog and asked to work on features that deviate from the original plan. More problematic is the fact they they begin getting confused about the direction of the product, the market it serves, and the problem being solved. You enter a state of continual scope creep and the original vision of the product deteriorates into a fragmented collection of features. The initial problem of cash flows is further exacerbated in the long term as you find yourself with a product that poorly solves a number of problems rather than effectively solving one problem. The most detrimental sales actually result in a long-term increase in your costs if the deal does not fit with your cost structure. The best example of this is promising a highly customized solution when you have a mult-tenant application with few customization options.

Under a lean startup approach these sales tactics either slow down, or completely destroy the build-measure-learn feedback loop. Developers simply make the leap from one build phase to the next, and never exit the loop, thus no learning takes place.

From a customer perspective it’s important to remember that with hosted SaaS style solutions client satisfaction and problem-solution fit are paramount. If the promised value is not delivered then users will simply stop paying. In addition to not paying, the over-promise, under-perform result will lead to negative referrals which will hurt future deals with clients that may actually be a good fit for the product.

This sort of cycle is easier to prevent than it is to stop, therefore it is important to take measures from the outset that will stop sales people from ever venturing down this path. One of the most effective tools is the creation of a user persona and communicating to all teams who your client is and what problem you are trying to solve. Make the completion of the minimum viable product your priority and only allow changes only based on validated and significant feedback. Some good rules to follow are:
  • Any in progress stories should be completed before moving on to a newly proposed feature. If you are using scrum and sprints, the new feature cannot be started until the next sprint.
  • A feature should only become a candidate if several sales meetings have suggested a need for it. At this point the feature should be tested with the existing client base through discussion or MVP style tactics (e.g. dummy pages, beta signups, etc.). If the feature is proven valuable and important to your current and potential users you can start to prioritize it. The first step in prioritization is determining its ROI, or simply its benefit to developer effort ratio. The benefit is particularly important to drill down on as you’ll need to consider whether it will it result in higher conversions, higher upgrade rates, or wider adoption. If wider adoption is the source of the benefit I recommend holding off until the product serves its current target user base as well as it can. If the ROI proves attractive add it as a story and let it marinate in your backlog for a little while, never jump into the feature right away. If the feature is still relevant in a month then fit it into your development schedule.  
  • Feature additions or changes need to be decided on by a group of employees. This group should contain developers, product managers, sales people, and user experience designers. This way you can flush out all the implications of the proposed change, an effective solution can be found, and cross-functional buy in can be had.
  • Features should generally only be added if you’ve exhausted the product’s current target market
  • If you’re in the process of developing features for one target market, features for another target market should only be added in the context of a pivot. Simply put, your sales team has determined that you are pursuing the wrong market and are changing the direction of the product to serve this new target market. If you’re not changing direction then leave the feature somewhere and come back at a later time.
If the cycle has already begun, it’s critical to address the issue with the management and sales teams and implement the above safeguards. Most importantly develop the client persona and articulate the problem this user is having. This persona will serve as a simple test for client leads and will aid in filtering out a great deal of incompatible deals.

Some Common Justifications
You’ll typically hear several justifications for closing an ill-fitting deal but rarely are they valid.
  • “We can learn about how this type of customer works” This is never a good reason as you should be learning how the customer works before starting development. Remember that you need to learn how this customers broader market works, not just how they work.
  • “This deal is highly strategic and will provide lots of future [insert dubious benefit]” This is one of the toughest calls to make as there is always the thought that a certain partnership will lead to future success. Occasionally they are beneficial, but from my experience these “strategic” partnerships rarely play out as expected and typically underperform. What you are doing here is making an up-front investment in the hope that it will result in long-term revenue generation. In effect this is the same as what you are trying to do with your existing product vision so why not proceed with that? Just remember that strategic partner ships vary greatly in their success, rewards are sometimes one-sided, and that they can only be beneficial if you have a finished product. 
  • “Just this one time” It’s never one time, it’s merely the start of a vicious cycle.
What Your Sales Team Should Be
In the early stages of your business the focus should be on validation and learning. The sales team should therefore work towards optimizing these two critical components with an emphasis on long-term value rather than short-term cash flow. Your sales people will need to be part salesman, and part product manager. They need to close the deal when it’s a good deal, and listen when it’s not a good fit. While a client may not be a good fit for the current version of the product, they may present insights on where the product can go in the future, or perhaps that you’re targeting the wrong market and a pivot is needed. To get these results from the sales teams the incentives have to be aligned accordingly. Commissions have to be paid based on long-term user retention and the profitability of closed deals. If a $100/month sale results in $5000 in up-front development and acquisition costs it’s hardly a successful sale.

There is a great saying that “strategy is not about what you do, it’s about what you don’t do”. Remember that in business it’s easy to “yes”, it’s saying “no” that’s hard, but it’s the no’s that define the success of a product. Everyone is always hesitant to cut features, refuse features, or turn down clients, but it’s a reality of software development. Potential clients are never gone forever and if they’re not a good fit today, they may be tomorrow. After all, if the client is even talking to you today then they are clearly willing to change their current way of doing things. Always remember that in the early stages of your business you need evangelists, not detractors (think net promoter score). Focus your efforts of providing a best-of-breed solution to your target market and aim to under-promise and over-deliver.

If you liked this post please follow me on Twitter for more.

Sunday, March 13, 2011

Lean Design For The Lean Startup

The question of design and usability in a lean startup is a common one. How much effort does one expend in making the user interface look good, particularly in a minimum viable product. It's a question that I briefly addressed in a previous post (The Minimum Viable Product Dissected), but it's one that I feel warrants a more in depth discussion. As Eric Ries has rightfully explained, at the early stages of your startup you really don't know who your user is, so creating a perfect user experience is simply not possible. I believe Dave McClure sums up the Minimum Viable Design concept well: "What is the shittiest you can do but still be awesome?". This is a good way to think about it, but it still begs the question of how shitty can you really go, and what is awesome?

How Shitty?
First off, your product doesn't have to be stunning to be effective or become popular. This is a common misconception as most people believe that "sex sells" and that "you don't sell the stake, you sell the sizzle". As with most things in life, the initial infatuation with a sleek design is short lived and eventually it is substance that drives repeat use. In the context of the AARRR model, a pretty design is applicable only partially to the activation metric, while retention, referral, and revenue are driven heavily by the value proposition and function of your product. If you have to work your ass off to dazzle people with a pretty interface, then you're not solving a real problem of theirs and simply haven't found product/market fit. What I therefore recommend is that you spend time perfecting your first impression. Have your designer spend the bulk of their time on the landing, registration, and sign-on pages, then focus on function over form in the rest of your application. A caveat, however, is that design is useless on these pages without impeccable copy. Although good design will make your product look professional, good copy is what drives conversions.

Spend time A/B testing these pages and continue iterating until the degree of marginal improvement gets low. While quantitative metrics from A/B testing are good for measuring the effectiveness of your copy, design should include a mixture of quantitative and qualitative feedback. While A/B testing can tell you whether your design choice improves conversions, it's important to find out why this is the case. Does your specific market value a certain aesthetic or style? Do they associate the design with something intangible? It's important to draw out these pieces of information, as it can help drive the direction of the rest of your application, particularly since this data can be gathered early on. So how shitty can you go? Well if we take Reddit as an example, I think the UI looks pretty shitty and I probably would have pushed for a nicer design. I, however, would have been wrong as the site garners 1B+ page views per month and it seems like most people don't care and they think Reddit is awesome. So to clarify Dave McClures point, your UI can be shitty but your function has to be awesome.

It's All Relative
I posit that your design decisions should largely be driven by the nature of your product, the competitors you're up against, and your unique selling proposition (USP). If you are delivering a sustaining innovation that improves upon the functionality or means of solving an existing problem in a competitive market, then surely your design has to be better, right? In a sense this is true but you first have to determine what elements of the design/function you have to optimize and to do this you have to figure out what "better" is. Are your users expecting your product to help them do something faster, more effectively, or cheaper? Once again these are things that you should be able to find out during your early MVP by playing with copy, doing AdWords experiments, and simply talking to people. If it turns out that your customers want a cheaper way of doing something, then providing a best in class, highly dynamic interface won't help you become a low cost provider. However, if your USP is the ease and speed of doing something, then providing a highly responsive rich Internet application interface will be important.

In the case of a disruptive innovation, the situation changes to a large extent. At this stage your design decisions are more clear cut, as market risk will be your primary challenge. With disruptive innovations your early customers will be innovators and early adopters, so the design should typically be minimalist and geared entirely towards learning and experimentation. If you provide an interface that is easy to navigate - and it should be since you have a minimum level of functionality - and looks semi professional, that's all that is needed. You shouldn't be worried about the use of gradients, shadows, or fuss over the specific shade of blue your button should have, as you've got way bigger problems. Once you've validated your idea and have moved on to company building and crossing the chasm, armed with the learning you've done, you can than begin developing a great interface.

Step By Step
Ultimately, we arrive at the basic premises of the lean startup: build, measure, learn, and iterate. In your early MVP, which is likely a landing page with a signup box, I recommend not skimping on design. Make it look good and perform a whole lot of A/B and qualitative testing. Gather as much information as you can and find out who your customers are and what they value. Use this data to set a design direction for your early functional prototype (as described above) and come up with a set of wire frames that employ a minimum number of consistent and simple components throughout. Your stylesheet should be nice and short, your color palate should be minimal and your graphic designer should be spending most of their time on the first impression pages. Remember, it's almost certain that you'll have to do a full re-design of your application as it evolves, so create a design that you won't mind throwing away. As you go through several iterations you'll have a better understanding of what aspects of design you need to focus on and what is really important to your users.

In the end, the beauty of your UI should never be your biggest worry at the early stages of your business. Your UI should serve as a canvas for delivering your value proposition and an unhealthy focus on aesthetics can detract from this delivery. Focus your time on perfecting copy and allow the design to evolve naturally. Once your copy has gotten users past the sign-up page, use tools such as Crazy Egg and to ensure that your basic interface allows them to achieve their intended goals. If you're solving an important problem for me, I'll never leave because I disagree with your choice of colors.

If you liked this post please follow me on Twitter for more.