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.
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.
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.