Startups Stack Exchange Archive

When is it appropriate to introduce new products?

I do not want to introduce too many products too soon. For a startup, what are some good guidelines to help know when it is the right time to expand my product line?

I have a web based business, where the cost of coding is equal to the time that I invest into the product.

Answer 122

Assumptions

  1. You have a backlog of products to release (more time spent on development, not design)
  2. You are not spending a lot of time on sales / marketing
  3. You are not spending a lot of time on customer service

Depending on how much time you have to dedicate to the company, I’d move on to the next product as soon as possible.

Once your first product has reached the point of a commercial release and requires minimal maintenance, I would focus development efforts on a new product or enhancements on existing products. I’d just strongly advise against getting comfortable with a single product.

Answer 125

It depends on your overall business plan. If you are developing small utility types products then go for numerous, however as you will notice, most big companies all focussed on one product initially.

Coming from experience, multiple products, means multiple headaches. Try to boost your existing product or focus on more sales and marketing rather than coding.

Stick to one product with a main focus on solving a specific problem as best you can.

Answer 144

Don’t outdo yourself. That’s the number one piece of advice I can offer. A lot of really cool companies launch, then, high on adrenaline, launch again, then again, and suddenly they have several mediocre products out there that water down their branding and support capabilities.

If you have really cool innovations, file the appropriate intellectual property registrations and sit on them for a month or two while you let your flagship product gain traction. Once you’re comfortable with how it’s doing, launch another.

Think about how the products interact, too. Let’s just, for the sake of argument, consider a fictitious version of a Microsoft Office suite competitor.

We’ll start off our venture into entrepreneurship with the launch of a word processing application. That’s great. We start picking up market-share in word processing as we grow and add on features. Here’s one solid piece of software that’s used by a lot of people, we’re comfortable supporting it and granting updates as appropriate. We’ve got some other ideas lined up, but let’s be sure we’ve got this covered before we worry too much about those.

As time progresses, we start to see something lacking: people want a great way to make tables and spreadsheets that has native interoperability with our word processing architecture that’s already been making big news. With that market knowledge, we develop an Excel-equivalent. Our word processor is fairly prone to success at this point, with fewer and fewer bug reports each week. We’re now comfortable to support the spreadsheet application just as we did the document one. The two build off each other, which puts our existing customers on the shortlist to buy from us again, and sets up anyone who didn’t originally need word processing but does need spreadsheets to look into buying a bundle.

But let’s say we get a bit of a rush over us. We’ve tasted–er–success, and we want more. We want to be first-in-the-door in the exciting new cloud storage arena. So before we’re really comfortable to let our spreadsheet software fly off into the sunset, we throw in a cloud storage infrastructure that works with our two other packages. It’s exciting and gathers a lot of buzz, but suddenly we find ourselves caught in the headlights of two speeding trains from two different directions. On our left is a growing user-base for spreadsheets. People have bugs, feature suggestions, complaints, and all sorts of input. Then on the other side, there’re server issues, people can’t always get at their files, it can get slow, and we’re just facing all these issues at once. On their own, resulting bugs from either release would be a task to behold, but we could handle them. But together, it’s increasingly daunting.

So where did we go wrong? We captured interest, we developed good products (as good as an early release can be), and yet we suddenly found ourselves trapped between a rock and a hard place trying to fight off a swarm of users, disappointed over our decrease in service and support.

I think the “ideal balance” is probably just a myth. It’s super difficult by any measure to give a really good answer to a question like this. It depends on the market you’re in, the users you have, the users you want, the products you’ve lined up, your team size, even what time of year it is. There is a countably infinite collection of variables stacked against your predictive analytics and intuition.

But in general, personally anyway, I would shy away from launching two extremely unrelated pieces of software at once. In this story of mine, the Excel and Word equivalents benefitted from each other because they found use from the same sorts of people. But if we had thrown, say, a Photoshop competitor into the mix, we would have been forced to deal with another whole monster at no real business gains.

So you just have to think about your products and your team and decide:

  1. Can we support these products coming out at once?
  2. Do people want these products to come out at once, or can we afford to hold off a bit?
  3. Is one product more important than the other for one reason or another?

Think about the ecosystem that you’re building for your products. If they support each other, that’s a much better reason for quick-successive launches than if you just want to quickly corner two markets all at once. If one can wait, let it.

Remember, too: nobody will ever think less of your business because you took a little while to release a second great product. It’s a calculated risk to launch two at the same time, and the financial benefits might make it worth it. But if you launch an awesome product, wait a few months, then launch another stellar one, people will like you. If you launch two mediocre ones at once, well, that becomes a bit more difficult to predict.

Answer 12828

You should develop a timely flow for when new products should be released. This should happen naturally after you have developed a successful product release process. If you spend more time building the product, design and marketing included, you will find that your product releases will automatically spread themselves out.

I suggest looking into what more you can do to ensure your product reaches its full potential at its release, rather than pushing new half-thought-out projects out in a quick manner. Good luck!

Answer 13442

I personally vote for business logic. only launch new product when:

1- there’s a demand for it, 2- you can sell it, 3- is in harmony with the other products your current users have (or can be a good base for your next products).


All content is licensed under CC BY-SA 3.0.