(note: on the path to building a software product, there are lots of decisions to make - but perhaps the toughest is trying to decide what type of project /product you want to build. This post describes some of the issues involved - if you've got other ideas, agree or disagree, I'd love to hear about it)
Schedule. Schedule. Schedule
Do you want to be all things to all people from the get-go? Or do you want to grab people's attention quickly and then build functionality based on a longer term vision.
The decision you make will greatly affect how long your entire project will take.
All Things to All People
This approach means you don't plan on releasing a product until it does everything you think it should do across the board.
While the one huge benefit is that you will be able to say "Yes - we can do it" to potential customers, there are several problems with this approach.
Benefits
"Yes - we do that"
It's always great to be able to say to a customer or potential customer "Yes, we do that" when they ask. It gives the customer a feeling of satisfaction knowing they have chosen a company who has already identified and solved the problem at hand.
Is this the same solution for every customer in that market or a single request from a specific customer? While many companies like to believe they are completely unique in their industry, there usually are a number of synergies that can be applied across a large customer base.
That said, there are many companies who request features because they have never done it any other way before and thus expect the same feature. By ensuring you meet every requested customer feature, you run the risk of bloating your software.
To make this benefit work best, a document or feature matrix outlining everything your software does (and does not do - although by the definition of the concept, this should be fairly limited) is necessary.
"Here's how we do that"
A partner of the "Yes - we do that" benefit is the ability to describe to potential customers precisely HOW you do it. This can offer a huge "relief" factor when discussing implementation issues or strategies with customers.
White papers, demonstrations and presentations are the best tools here - allowing everyone in the organization to understand how each cog in the wheel works.
Identifies strategic partners early
While there will always be some areas that you "cannot" do, you can identify the leaders in those areas and form valuable strategic alliances.
This is incredibly valuable as you will be able to prepare for questions that they have come up with, and also be ready to answer those "can you do?" questions.
Choosing strategic partners can be tricky. Many want to be your "sole- source" which, many times, can be the equivalent of your "soul-source" - you are limited to their limitations as well.
Instead, consider many partners, including some in the same industry. You will always need to choose a "preferred" partner - but you can do that when you absolutely need to.
Risks
When will it be ready?
Simply put, more features mean more time. More time to develop, more time to document, more time to test, more time to debug.
If you have an unlimited schedule, great - if not, you have to be able to identify to both your customers and yourself when you expect everything to be ready and then get all of the resources ready to commit to that time.
Is everything being tested?
It's not enough to have enough developers on the project - everything needs to be tested --- by people who will actually USE the feature, instead of those who develop it.
Following a principle of "test early, test often" is the best approach to accomplish this. Expect that developers are doing unit-tests, higher level developers are doing integration tests but also that testers know every possible permutation to test for.
Are we too late?
If you have a long development cycle, the biggest risk is that by the time you are done, your customers or potential customers have already moved onto another platform. You may have the next great gas-powered engine in the world, but if the rest of the industry has moved onto electric or hydro- powered engines, all of that effort will be useful only as an experience barometer.
What did we miss?
Almost as bad as being late is missing something that came out while you were busy working on something else (classic example: Microsoft and the Internet).
Adding new things late in the development cycle is (almost) always a recipe for disaster unless your development process allows for it. Communicating with your potential customers is always a good way of identifying what you might be missing - but keeping your ear to the ground of everything that's going on is just as crucial.
First Out of the Gate
"First out of the gate" doesn't really mean you were the first to do it anymore but it does mean that you are offering something of value right off the bat that other companies may not or may not do the same way.
Instead of taking the "everything but the kitchen sink" approach, you identify certain key features, strip them down to the bare minimum and offer them immediately, allowing you to upgrade them as demand requires.
Benefits
Faster to build
If you only have to build a tire swing, chances are you'll be done before the person who is building a jungle gym with a swing.
Having a smaller simpler product also makes it easier to add features or to evaluate them later on by keeping a short tight development cycle.
Ship early, ship often is a mantra in many development circles. While it does let you respond faster, it does have its risks.
New Features = New Announcements
Every company likes to promote new features - and the more announcements you make, the better the chance of getting picked up in industry or mainstream press.
Building a smaller application and adding features is also a great way of showing how you are growing your product line. A great example of this is OpenAir - a company that schedules new features once a month. They may be the tiniest feature, but it has grown a very small time-tracking and project management tool into a huge online professional services offering.
Respond to demand
Releasing sooner also lets you get feedback sooner and respond to demand based on the most popular features.
It is the perfect opportunity to solicit feedback from customers as well - because you now have actual customers who are committed to your product.
The other big benefit here is word of mouth - if you have 10 customers and you add a new feature regularly that is requested by 8 of them, it's not just responding to their demand - it also shows them that you care about what they want - a trait that people love to talk about.
Opportunity to link and play well with others
If you only do one thing but do it well, you may find that others who provide other related services (in the same fashion) want to work with you. By opening up to others, you can build an entire network of partners who offer different but complementary services. You may decide to go into a similar area if you find some features that are lacking in a given tool - but otherwise, it might let you focus on a different area.
Easier to test
Simply put - less features to build, less features to test; less features to test, easier to test.
If you have a 5 key features in your product and a team of 5 testers, they can likely do all of the testing on the product in much less time, than if you had 25 key features with the same test group.
It also ensures that the little things that testers (or worse, users) typically find at the last minute can be found faster and earlier because there is more time to do good testing.
Risks
Do you offer enough?
If you built a product with feature A, but customers need a product with features A+B, then you either have to have a solution for B, are bringing out B soon after or will lose the customer.
This is why it's critical to define at the lowest possible level exactly what features are needed and will be built.
Too little, too early
If you don't offer enough functionality, then it doesn't matter if you were first - someone will pick up on it and offer the needed functionality in about half the time because they can piggy back on your initial work.
This is the downside of the "ship early, ship often" approach. You show your features to the world and unless you can really capitalize on it, your competitors will instead.
Possibly viewed as "limited"
No one wants to be seen as "limited" - "targeted" or "specific" is better as it shows a single- mindedness to a particular task. But "limited" is a killer term. However, if you are hitting the "new features" with a "fast to build" approach, this risk can be easily reduced or at least, addressed.
Requires ability to say No
This is where personalities play into it. If you (or your managers or partners) can't say "no" to requested features, then you can't hit this approach. It's the corollary to "Yes - we can do that" - you must be able to say "No, that isn't our current focus".
A great example of this ability is 37signals, the company behind Basecamp, who have explicitly said "we are NOT a full-blown project management site" - their focus is on small-team collaboration on projects.
It also requires a single focus - at least for a given feature. SO that everything the company or group does is focused on that one task, instead of several, so that they can get it done and then move onto the next big feature.
------
Do you have a particular approach you use for projects?
Schedule. Schedule. Schedule
Do you want to be all things to all people from the get-go? Or do you want to grab people's attention quickly and then build functionality based on a longer term vision.
The decision you make will greatly affect how long your entire project will take.
All Things to All People
This approach means you don't plan on releasing a product until it does everything you think it should do across the board.
While the one huge benefit is that you will be able to say "Yes - we can do it" to potential customers, there are several problems with this approach.
Benefits
"Yes - we do that"
It's always great to be able to say to a customer or potential customer "Yes, we do that" when they ask. It gives the customer a feeling of satisfaction knowing they have chosen a company who has already identified and solved the problem at hand.
Is this the same solution for every customer in that market or a single request from a specific customer? While many companies like to believe they are completely unique in their industry, there usually are a number of synergies that can be applied across a large customer base.
That said, there are many companies who request features because they have never done it any other way before and thus expect the same feature. By ensuring you meet every requested customer feature, you run the risk of bloating your software.
To make this benefit work best, a document or feature matrix outlining everything your software does (and does not do - although by the definition of the concept, this should be fairly limited) is necessary.
"Here's how we do that"
A partner of the "Yes - we do that" benefit is the ability to describe to potential customers precisely HOW you do it. This can offer a huge "relief" factor when discussing implementation issues or strategies with customers.
White papers, demonstrations and presentations are the best tools here - allowing everyone in the organization to understand how each cog in the wheel works.
Identifies strategic partners early
While there will always be some areas that you "cannot" do, you can identify the leaders in those areas and form valuable strategic alliances.
This is incredibly valuable as you will be able to prepare for questions that they have come up with, and also be ready to answer those "can you do?" questions.
Choosing strategic partners can be tricky. Many want to be your "sole- source" which, many times, can be the equivalent of your "soul-source" - you are limited to their limitations as well.
Instead, consider many partners, including some in the same industry. You will always need to choose a "preferred" partner - but you can do that when you absolutely need to.
Risks
When will it be ready?
Simply put, more features mean more time. More time to develop, more time to document, more time to test, more time to debug.
If you have an unlimited schedule, great - if not, you have to be able to identify to both your customers and yourself when you expect everything to be ready and then get all of the resources ready to commit to that time.
Is everything being tested?
It's not enough to have enough developers on the project - everything needs to be tested --- by people who will actually USE the feature, instead of those who develop it.
Following a principle of "test early, test often" is the best approach to accomplish this. Expect that developers are doing unit-tests, higher level developers are doing integration tests but also that testers know every possible permutation to test for.
Are we too late?
If you have a long development cycle, the biggest risk is that by the time you are done, your customers or potential customers have already moved onto another platform. You may have the next great gas-powered engine in the world, but if the rest of the industry has moved onto electric or hydro- powered engines, all of that effort will be useful only as an experience barometer.
What did we miss?
Almost as bad as being late is missing something that came out while you were busy working on something else (classic example: Microsoft and the Internet).
Adding new things late in the development cycle is (almost) always a recipe for disaster unless your development process allows for it. Communicating with your potential customers is always a good way of identifying what you might be missing - but keeping your ear to the ground of everything that's going on is just as crucial.
First Out of the Gate
"First out of the gate" doesn't really mean you were the first to do it anymore but it does mean that you are offering something of value right off the bat that other companies may not or may not do the same way.
Instead of taking the "everything but the kitchen sink" approach, you identify certain key features, strip them down to the bare minimum and offer them immediately, allowing you to upgrade them as demand requires.
Benefits
Faster to build
If you only have to build a tire swing, chances are you'll be done before the person who is building a jungle gym with a swing.
Having a smaller simpler product also makes it easier to add features or to evaluate them later on by keeping a short tight development cycle.
Ship early, ship often is a mantra in many development circles. While it does let you respond faster, it does have its risks.
New Features = New Announcements
Every company likes to promote new features - and the more announcements you make, the better the chance of getting picked up in industry or mainstream press.
Building a smaller application and adding features is also a great way of showing how you are growing your product line. A great example of this is OpenAir - a company that schedules new features once a month. They may be the tiniest feature, but it has grown a very small time-tracking and project management tool into a huge online professional services offering.
Respond to demand
Releasing sooner also lets you get feedback sooner and respond to demand based on the most popular features.
It is the perfect opportunity to solicit feedback from customers as well - because you now have actual customers who are committed to your product.
The other big benefit here is word of mouth - if you have 10 customers and you add a new feature regularly that is requested by 8 of them, it's not just responding to their demand - it also shows them that you care about what they want - a trait that people love to talk about.
Opportunity to link and play well with others
If you only do one thing but do it well, you may find that others who provide other related services (in the same fashion) want to work with you. By opening up to others, you can build an entire network of partners who offer different but complementary services. You may decide to go into a similar area if you find some features that are lacking in a given tool - but otherwise, it might let you focus on a different area.
Easier to test
Simply put - less features to build, less features to test; less features to test, easier to test.
If you have a 5 key features in your product and a team of 5 testers, they can likely do all of the testing on the product in much less time, than if you had 25 key features with the same test group.
It also ensures that the little things that testers (or worse, users) typically find at the last minute can be found faster and earlier because there is more time to do good testing.
Risks
Do you offer enough?
If you built a product with feature A, but customers need a product with features A+B, then you either have to have a solution for B, are bringing out B soon after or will lose the customer.
This is why it's critical to define at the lowest possible level exactly what features are needed and will be built.
Too little, too early
If you don't offer enough functionality, then it doesn't matter if you were first - someone will pick up on it and offer the needed functionality in about half the time because they can piggy back on your initial work.
This is the downside of the "ship early, ship often" approach. You show your features to the world and unless you can really capitalize on it, your competitors will instead.
Possibly viewed as "limited"
No one wants to be seen as "limited" - "targeted" or "specific" is better as it shows a single- mindedness to a particular task. But "limited" is a killer term. However, if you are hitting the "new features" with a "fast to build" approach, this risk can be easily reduced or at least, addressed.
Requires ability to say No
This is where personalities play into it. If you (or your managers or partners) can't say "no" to requested features, then you can't hit this approach. It's the corollary to "Yes - we can do that" - you must be able to say "No, that isn't our current focus".
A great example of this ability is 37signals, the company behind Basecamp, who have explicitly said "we are NOT a full-blown project management site" - their focus is on small-team collaboration on projects.
It also requires a single focus - at least for a given feature. SO that everything the company or group does is focused on that one task, instead of several, so that they can get it done and then move onto the next big feature.
------
Do you have a particular approach you use for projects?
Comments