The *business* of software
How to decide on sets of functionality that are competing for development resources?
Sorry for the longish post, but I figure it best to try and be as complete as possible when posing this type of business-focussed question.
This is a question about how to choose which sets of functionality or enhancements to devote engineering resources to address when the sets are seemingly equally worthy of attention but which address the needs of different user constituencies. How do I get our product to avoid becoming a semi-competent "jack" of some trades (desirable solutions), but "master" (i.e. attractive to current and potential customers) of none?
A few months ago, I left my safe, corporate job to take charge at a very small (2 developers plus myself half-time on the dev team) software company - and I'm loving every minute of it. The workload is heavy and my wife is due to deliver our first baby any day now. Maybe I'm a glutton for punishment 'cause I wouldn't have it any other way right now, even with this poor economy.
We have an existing on-demand product sitting on top of Salesforce.com that helps sales managers to more effectively assess and manage regular revenue forecasting with their teams - an important process in most B2B sales organizations. To-date, the functionality has been very focussed at the sales managers, with a mixture of tactical functionality (helps them work with Salesforce easier) and strategic/analytical tools (take a step back and assess how we're performing, what type of trends are apparent, how can I address issues).
Our existing product functionality definitely needs more enhancement and polishing. The previous team took the approach of "let's build this cool functionality and people will figure out how to apply it". I come from the school of thought that you build an app based on (somewhat) clearly understanding the problem/question that someone wants solved/answered, and delivering functionality as appropriate. I'm slowly steering the application onto the latter course of being more user-friendly and understandable, and to-date have had a lot of positive feedback from current users and advisors on our most recent releases.
We've gotten some great feedback that this type of application is only useful if the sales team is actually following best practices for data management, something that Salesforce doesn't necessarily enforce or facilitate in a usable or value-producing manner. As such, we're looking at creating a lightweight interface for sales reps that makes it ridiculously easy for them to CRUD the core information for effective opportunity management and revenue forecasting - and view it in context of how they are projected to perform for the current or future fiscal period. Think of it as the "universal remote" (a good one) for sales reps.
Attacking this set of functionality could draw our limited engineering resources away from enhancing our existing tactical and analytical tools for sales managers. With only two full-time developers, I am hesitant to point them in different product directions as what they synergistically produce is far better than what they could produce alone. Time is of the essence. We’re not completely boot-strapped: we’ve got about 8 months of funding runway, but are currently seeing only about a sixth of the revenue from existing customers necessary to get us to a cash-flow neutral position.
I figure there's a few approaches I can take:
0) buff and polish our existing functionality before moving onto anything new. Remove spurs, splinters and the like, causing the villagers (existing customers) to dance in the streets and hail our very existence. We may not be delivering much of the new functionality necessary to expand their usage or attract many new customers.
1) build out whole-heartedly either the rep-focussed tactical functionality (universal remote) or the manager focussed analytical functionality. Spend an afternoon each week on buff/polish from point (0).
2) move in all three directions (buff/polish existing; new tactical functionality; new analytical functionality), focussing on a different one each iteration (currently at two weeks). This way the app progressively becomes better in each area. However, no one area receives the necessary love to move it forwards in leaps and bounds in a shorter timeframe (e.g. 2 or 3 months).
Any words of wisdom, advice, warning, or even gentle mockery would be greatly appreciated.
This is a question about how to choose which sets of functionality or enhancements to devote engineering resources to address when the sets are seemingly equally worthy of attention but which address the needs of different user constituencies. How do I get our product to avoid becoming a semi-competent "jack" of some trades (desirable solutions), but "master" (i.e. attractive to current and potential customers) of none?
A few months ago, I left my safe, corporate job to take charge at a very small (2 developers plus myself half-time on the dev team) software company - and I'm loving every minute of it. The workload is heavy and my wife is due to deliver our first baby any day now. Maybe I'm a glutton for punishment 'cause I wouldn't have it any other way right now, even with this poor economy.
We have an existing on-demand product sitting on top of Salesforce.com that helps sales managers to more effectively assess and manage regular revenue forecasting with their teams - an important process in most B2B sales organizations. To-date, the functionality has been very focussed at the sales managers, with a mixture of tactical functionality (helps them work with Salesforce easier) and strategic/analytical tools (take a step back and assess how we're performing, what type of trends are apparent, how can I address issues).
Our existing product functionality definitely needs more enhancement and polishing. The previous team took the approach of "let's build this cool functionality and people will figure out how to apply it". I come from the school of thought that you build an app based on (somewhat) clearly understanding the problem/question that someone wants solved/answered, and delivering functionality as appropriate. I'm slowly steering the application onto the latter course of being more user-friendly and understandable, and to-date have had a lot of positive feedback from current users and advisors on our most recent releases.
We've gotten some great feedback that this type of application is only useful if the sales team is actually following best practices for data management, something that Salesforce doesn't necessarily enforce or facilitate in a usable or value-producing manner. As such, we're looking at creating a lightweight interface for sales reps that makes it ridiculously easy for them to CRUD the core information for effective opportunity management and revenue forecasting - and view it in context of how they are projected to perform for the current or future fiscal period. Think of it as the "universal remote" (a good one) for sales reps.
Attacking this set of functionality could draw our limited engineering resources away from enhancing our existing tactical and analytical tools for sales managers. With only two full-time developers, I am hesitant to point them in different product directions as what they synergistically produce is far better than what they could produce alone. Time is of the essence. We’re not completely boot-strapped: we’ve got about 8 months of funding runway, but are currently seeing only about a sixth of the revenue from existing customers necessary to get us to a cash-flow neutral position.
I figure there's a few approaches I can take:
0) buff and polish our existing functionality before moving onto anything new. Remove spurs, splinters and the like, causing the villagers (existing customers) to dance in the streets and hail our very existence. We may not be delivering much of the new functionality necessary to expand their usage or attract many new customers.
1) build out whole-heartedly either the rep-focussed tactical functionality (universal remote) or the manager focussed analytical functionality. Spend an afternoon each week on buff/polish from point (0).
2) move in all three directions (buff/polish existing; new tactical functionality; new analytical functionality), focussing on a different one each iteration (currently at two weeks). This way the app progressively becomes better in each area. However, no one area receives the necessary love to move it forwards in leaps and bounds in a shorter timeframe (e.g. 2 or 3 months).
Any words of wisdom, advice, warning, or even gentle mockery would be greatly appreciated.
Views: 1
Replies to This Discussion
-
Permalink Reply by Ken Hughes on -
Wow - tough one...
So, before diverting resources onto the new project (lightweight interface/tactical version?) I'd want to be sure that it will fly - so I'd look to produce a demo/PoC/limited functionality version to use for testing the market - do people like it and (more importantly) will people part with cash for it...
Along side that I would take a long hard look at the current product - if you need six times the volume to become cash neutral then what will be required to get six times the sales - is that even realistic, do you need to face some hard facts and kill it ?? OR is it just a case of getting a bit of polish on it, and providing an easy way for your customers to recommend/evangelise it to others...
How confident are you that the new analytics features will enable the six fold (at least) increase in sales.
I wouldn't just focus solely on buff and polish only - it might make your customers happy but what good is that if you run out of money in 8 months ?? But this is something I'd struggle with deciding on, there is a balance to be had between neglecting customers and pandering to them, what you want is enough to keep them interested while bearing in mind that it is easy to get a bad name but very difficult to get (and maintain) a good name....
Sorry, there doesn't seem to be many answers here - hope it helps though...
.. KJ
-
Permalink Reply by Perry Ismangil on -
I have a similar situation in our company. We have a choice of adding video support, or stick with audio only but get it to run better on more and more platform.
Both markets are booming, both have prospects saying they will buy it.
So we went back and thought hard about who we want to be, which our tagline is Communicate Anywhere. So we decided to do the more platform work, which in this case is better support on mobile devices.
In your case, you do have to decide which will bring the fastest and biggest money in. Which one is more attractive to the 'economic buyer', that is who will pay to solve their pain.
-
Permalink Reply by Stewart on -
What are business drivers? Is revenue everything? If so, then option '0' is likely the wrong option. If you are working on building customer satisfaction rates, reduce support calls then option '0' is likely the best option.
Perhaps try and pick some of your best customers and do some call reports to see what they are saying, also some win/loss analysis would be immensely useful.
Stewart
http://twitter.com/StewartRogers
-
Permalink Reply by Peter Degen-Portnoy on -
There is some good advice here. Talk to your customers and prospects, and focus on revenue generation.
You say that you have about 8 months of operations and you need a 6X growth to be self-sustaining. While increasing revenue will extend your runway, I recommend conservative planning: use reasonably low growth rate projections that are ideally based upon historical evidence.
That said, were I in your place, I would next work up cost/benefit comparisons of each approach. How much will it cost to pursue each approach and how much would revenue increase over time? Even if you were to build only a prototype of the new functionality, there would be a cost to that work. What are the risks in each approach? Can you reasonably eliminate and mitigate the critical risks? For example, is it reasonable that you can produce something compelling at the end of each 2-3 week sprint? One imagines that you will need deliverables at the end of each effort to make the effort worth while.
Here's another idea: Do you have any customers who might be very interested in the Universal Remote or Universal Analytics functionality that might be willing to help defray development costs for first use and customization rights? That way you get to build a prototype, grow it into something real while getting additional income from a customer who is already happy with you? They get a custom application before it gets released to the general market with special features that won't be released that will give them a competitive edge.
I think your strategy should be to establish reliable revenue while looking for opportunities to extend your development runway. Right now, it seems that you can do that by increasing customer revenue, or finding new revenue sources (new product line, partnership for new product development), or both.
Good luck and please let us all know how things work out.
-
Permalink Reply by David Locke on
-
You have bigger problems that resource allocation.
You need to get the bad data problem under control, because without good data, no one can manage anything.
Who pays for this? Do sales reps pay for this? Do sales managers pay for this? How does the sales manager enter the sales compenstion policies into the application and ensure that they are followed?
"Opportunity management" is not a sales reps job. They do "Engagement management." Opportunity management is something done amoung a pool of partnering vendors so that channel conflict is avoided. Opportunities lead to engagements. Opportunity management is done at a level above the sales rep's sales manager. You might consider it to be another application that you can cross sell.
Who inside your company is a sales manager? Or, are you getting your requirements from outside the company? Is the meaning underlying the sales or sales management domain being destroyed?
Are your customers sales reps or sales managers. From your comments, it seems clear that your customers cannot be both.
-
Permalink Reply by allan kelly on -
As others have said talk to your customers, look at your business objectives and see which move you in that direction.
You can also produce a product roadmap for the future showing how everything might come together. This should both help you understand what you are attempting and is something you can show to customers (in sanitized form) to get their feedback and (perhaps) buy a little time with them.
Have a look at Buy-A-Feature, http://buyafeature.com/ - if you have several people around who have views it might help you come up with an overall picture.
-
Permalink Reply by Mark Dalgarno on -
allan kelly said:
AllanYou can also produce a product roadmap for the future showing how everything might come together. This should both help you understand what you are attempting and is something you can show to customers (in sanitized form) to get their feedback and (perhaps) buy a little time with them
I've often wondered how something like a product roadmap fits in with an agile approach to software development. Roadmaps can really pin things down quite heavily [1] and at least intuitively don't feel particularly agile. (Or is there something magic about the 'sanitisation' process of which you speak...)
Mark
[1] I've experience of places where pinning things down heavily was in some cases a good thing and in some cases a bad thing. But there's no doubt that customers, sales people and to a lesser extent product managers like to map out some plan for what will be delivered in future releases.
-
Permalink Reply by Ryan Leslie on -
Thank you all for the replies. It does indeed come down to knowing what customers want, and working to satisfy both current and future customer needs.
For the record, we're going through a couple of iterations of "refinement": making our current functionality better, more solid, more friendly and useful. As we're doing this, we're also spending some time researching the next areas of functionality, and have a form of a roadmap. We are going to retrench with our manager-focussed application.
A roadmap can definitely pin you down if you don't appropriately message around it. The message I give people is one of proximity probability: the closer (in time) a feature is to today, the more likely it is that it will be implemented. In a world of agile product development, beyond 3-4 months is honestly a crapshoot.
-
Permalink Reply by David Locke on
-
Mark Dalgarno said:allan kelly said:
AllanYou can also produce a product roadmap for the future showing how everything might come together. This should both help you understand what you are attempting and is something you can show to customers (in sanitized form) to get their feedback and (perhaps) buy a little time with them
I've often wondered how something like a product roadmap fits in with an agile approach to software development. Roadmaps can really pin things down quite heavily [1] and at least intuitively don't feel particularly agile. (Or is there something magic about the 'sanitisation' process of which you speak...)
Mark
[1] I've experience of places where pinning things down heavily was in some cases a good thing and in some cases a bad thing. But there's no doubt that customers, sales people and to a lesser extent product managers like to map out some plan for what will be delivered in future releases.
Read "Software by Numbers" by Mark Denne and .... It talks about feature-driven design, an agile methodology. Using FDD you sequence the features to derive the optimum revenues over the life of a client engagement. The thinking there can be extended to software vendors. In my roadmap, I'll say that we are developing the core functionality in release A, and we are expanding a particular subsystem in release B, on and on. It's not a matter of specifying the details. The details can wait, but the releases are designed to generate revenues and cash flows. I'm not going to get into the details ahead of time. The roadmap tells the defacto customer, me, what I want. There is no need to sanitize anything. And, there are no discontinuities. The requirements for a given release are only very generally laid out in the roadmap. The details are delayed.
-
Permalink Reply by Perry Ismangil on
-
Mark Dalgarno said:I've often wondered how something like a product roadmap fits in with an agile approach to software development. Roadmaps can really pin things down quite heavily [1] and at least intuitively don't feel particularly agile. (Or is there something magic about the 'sanitisation' process of which you speak...)
Our roadmap consists of uncommitted stuff, from customers, community, ourselves. And then at the beginning of a 6-12 month cycle we'll commit to a big theme, and start pulling in stuff to make up a release. There is of course a mix of important bug fixes as well as new features.
So a roadmap can consist of hazy uncommitted stuff, with some of it becoming clear as a commitment for a certain release. But even that can be changed, where we say we'll release anyway and kick one or more stuff back to uncommitted.
Flexible roadmap, yes, rigid roadmap, no!
-
Permalink Reply by Lou Immendorf on -
Here's a short and long answer for you ...
Short answer = go with option 1 from your list and do not over build your solution
Longer answer
We sometimes struggle with similar issues in deciding which direction to go in dedicating developers when the it is difficult to know for certain which is the correct path to take especially if a great deal rides on your choice.
Here's what we do ... we learn as much as we can about the features that are going to be developed then we intentionally under build that area and have our sales folks demo the under built areas to existing as well as potential clients.
These demos provide very interesting feedback into our development process and sometimes help to provide funding in order to complete the work. One of the people who responded to you posting already offerred this idea up and it is one that has worked well for us.
We try to get our clients involved in our planning and development but we have struggled in this area. Our experience is that the clients are very busy (especially, now in the current economic situation) and are not for a variety of reasons interested.
-
Permalink Reply by Bill Horvath on -
Consider having a user's group meeting where some of your existing (hopefully local) customers can all meet with you and each other to discuss the options you're considering. (This might be a good thing to do at a salesforce.com convention, if they have one.) You'll have to frame the discussion carefully, but I think if you do it well they'll point you in the right direction.
Congratulations on the baby, BTW! Say goodbye to what little sleep you've been getting. :)
© 2012 Created by Neil Davidson.
Powered by 
.
