My experience with my current startup has been beyond educational.   There were some really high highs, and some extremely low lows.    I have never really been in believer in “I told you so”, I think it is counter productive and erodes the chemistry of an company.   However, I do think that using the past as a roadmap for the future is essential.

At some point in most startup’s lifecycle, especially if they are subscription revenue driven, they will come up against one of the big questions that will ultimately define then…is your development cycle driven by client needs and requests, or is it driven by internal criteria.

There are of course pros and cons to both sides of the issue.   I cannot say that one is head and shoulders above the other, but I can say that the path my company chose ended up effectively killing us in the end.

Development needs to happen, either scenario.

In our case, we had an enterprise level SaaS (software as a service) CMS.   Our initial goal with the CMS (pre-dating the evolution of Open Source to mainstream) was to have an “out of the box” solution that would allow customers to create and maintain a website without having to leverage any 3rd party vendors.    Now with any product in this space, it was going to have to evolve.   A product needs to stay up to date with emerging technologies and methodologies.   Everything from CSS3 to responsive design, etc.   That can be a full time job onto itself.   At the same time, your clients also really want to have features that are more niche to them.  Client driven development happens when you have a product, or in our case a piece of software, that can have features or improvements made to it that specifically pertain to a certain client or business category.

And thus,  you are presented with a paramount decision; how do you move your product forward to allow you to grab new customers and enter entirely new client categories; yet at the same time keep your existing customers happy and try to minimize customer attrition to the next “big thing”?   I have heard that some companies silo off the code base, and bolt on custom features for specific customers.    Others will simply add customer requests into the roadmap cue, and prioritize those request along with internal priorities.    There are many ways to skin a cat.   But before we dive into what we did, and why it didn’t work, lets look individually at each option a bit deeper.

Client Driven Development (CDD)

I would say the #1 driving factor in the client driven development corner is money.   A company needs money.   If your company’s lifeblood is recurring revenue, that revenue is great.  But in order to grow, you need to constantly search for new revenue streams.  CDD is a carrot that is constantly dangled in front of any enterprise SaaS product.   These companies want to have software that is specifically tailored to their needs.   Sometimes those needs are very similar to the overall needs of the product marketplace as a whole.  Sometimes these requests come from deep, deep roving right field.

CDD is beneficial from the standpoint that:

• It brings in additional revenue
• It allows your product to grow at the expense of a customer
• It provides the revenue cushion you need to allow for expansion and scaling of the business

That said, there are some distinct drawbacks:

• You have to structure some of your company to scope, track and fulfill these custom development items
• It slurps up development time that could be allocated towards internal product development goals
• Scoping is difficult.  Most clients (at least that we dealt with) have a good idea what they think they want, but they don’t really understand how their requested change could affect other areas of the software or of their workflow.    And once we roll up our sleeves and start working, there are always hidden trouble spots.

Product Driven Development (PDD)

In more companies, the prevailing opinion of the development side of the company is that PDD is the only development that needs to be done.   The age old battle between the sales/business side vs the development side of a software/services company is nothing new.    But moving your product forward has several strong merits

• PDD allows your product to grow and adapt to the ever changing landscape of web development.   It is not a luxury to account for PDD, it is a necessity.  If you don’t, your product will become obsolete in a matter of years, or even months.
• It is much easier to control the development cycle of PDD, because your core team understands what needs to be done, vs trying to interpret what a client is ultimately looking for.   Even the best PRDs still have some grey area.
• PDD is essentially development for the masses.  As a great vulcan once said, the lives of the many outweigh the lives of the few.    This is essentially PDD, developing features and tools based on competitor analysis, market trends, etc.  Those upgrades not only give your current customer base something new to play with on a regular basis, but it also improves the war chest your sales team has as their disposal.

Lest you think that PDD has no downside…

• PDD does not have any direct revenue tied to it.   Yes, you can path development that trys to open up new customer segments, but there is no guarantee that your development will directly result in sales.    And those developers working on PDD items, they are not “paying for themselves” with customer revenue
• Sometimes your product roadmap does not hit the mark.   Just because you identify where you need to move the product, that does not mean you decided correctly.

So…what is the way to go?

As I said earlier, every company will choose a different path.    Some companies have deeper pockets, because of venture funding.   They can do much more PDD initially because they have that funding to fall back on.  A boot-strapped company, as we were, will find it much more difficult to actually do a ton of PDD, because it does not pay for itself.    But, that right there, is where the decision needs to be made to do PDD.

My company, we tried different ways to handle PDD.   We tried allocating hours in each sprint for it.  We tried isolating one developer to focus on PDD.   But ultimately, we could not (or did not) allocate enough resources to PDD.

Now don’t get the wrong impression, CDD is essential to some degree.   There were several projects that started out as CDD that were ultimately folded into the platform, and because core elements of the product.    So CDD can actually have a silver lining, but it has to be done and controlled correctly.  Whatever the distribution of hours PDD vs CDD you take, my advice would be to remember these things

• Get your CDD scope as comprehensive as possible.   Scope creep was a killer for us, and on more occasions than not it blew our sprints out of wack.   Take the time you need to make sure that you have scoped the project completely.  Not only will this help your dev team stay on task, but it will also eliminate any grey area with customers when the project is complete.  Nothing is worse than a lukewarm response from a customer on a dev project.
• Always looks at a CDD project as an opportunity to for PDD.   One thing I always tried to do when scoping out CDD projects was to talk with the dev team to see how difficult the project would be ultimately bolt onto the main product.    By having this conversation with the dev team ahead of time, it got them out of the mindset of developing in an isolated silo and into the holistic product approach.    Best case, you would have to allocate an extra 20% of PDD hours after the project was done, and you could have a shiny, new feature for all your customers to enjoy.
• Don’t be afraid to say no.   This might be the most difficult one, especially for a CEO.  But sometime a client want something that just is counterproductive to the product, or such a massive project that it does not make sense.  There are several projects we took on that we should have just punted on.    We would have lost the revenue, yes.  But when a CDD request is so niche that a very small percentage of your customer base will use it, so time consuming that is absorbs your development team for weeks or longer, and so core that it involves augmenting or adjusting several core elements of your product; it is time to pass.  You will be better off for it.
• Always keeps a healthy ratio of CDD to PDD.   In the boot strapped world, it is extremely difficult to be 100% PDD driven.  Well, and stay in business.   But keeping, at a minimum, 25% of your dev hours allocated to PDD is critical.  Ideally you can keep it at 50-50.  But fight, and fight hard for that 25%.

What did we do?    Well, let’s just say that unfortunately we broke about every rule I listed above.   When there was a flood of CDD, it was great.  But eventually not moving your product along catches up to you.  And when it does, you will not be a happy camper.

E