Internet business is all profit rainbows and unicorns… NOT!
Nowadays technology flows freely. And what a tease the Internet is to everybody with an idea big or small. The American dream tells us everybody can be the next Zuckerberg. Yet reality is sometimes painful, like A LOT. All kinds of sources from Times to the Harvard Business School are pointing out that risk is something that needs to be considered and dealt with. Yet few word have been said on how to deal with a failure actually. How to leave with a smile and on good terms with users, your potential next projects’ customers.
Many have worked on failing projects at this or that part of their carrier. And all those reasons of fails differ one from another. Some allow everything to just flow quietly and are easily forgotten. Others will make you stand up and admit your errors and promise you will learn from them and not make them in the future.
We won’t be talking about the ‘why’ of a product failing. Lot’s has already been said on that matter. Let’s try to figure out our next step after admitting all is lost (well not all ‘ALL’, I just used the word to add some drama).
When do you notice that it’s time for the project to go?
- It’s a burden. A financial burden, which is the worst. The product is costing some cash to maintain, yet is not profitable. So why keeping it alive?
- It’s a burden. A resources burden. A good customer service has to be there, but do you have the staff to keep all that operational? Or would you rather them to do some more useful work?
- It’s a burden. A technical burden. Bugs and usability questions will keep popping up like flowers in spring. Who will be solving these issues? The staff you’ve taken from customer support to manage things that are more important?
- And the last, but not least, I guess we all know where this one is headed, it’s a burden. A legacy burden. If the project is causing issues with your other, more successful projects it can be considered a legacy burden.
Can’t I just keep it running? No harm’s done there right?
A pleasant option often occurs developers of all kinds. Why not just keep the project on its own flow. Just to display a massage that all support is ended and just to let it be. Everybody win’s you think. Users are pleased that they can still use the product, you don’t have to put any effort to it whatsoever.
This sound reasonable enough. But it’s just delaying the inevitable. The users will still be expecting bug fixes and the possibility of the product working on newer OS. That is just adding pain in the neck, and still you will have to follow your user’s demands. You don’t want to hurt your entire brand name, do you?
It’s the same as braking up. Hard yet necessary.
So you are now mature enough to close the product. It is too much of a burden. But you can’t just cut all the bridges in a second of time. You have your users to consider. When the product was released they’ve supported you. Even if it was totally free of charge, people have spent their hard-earned time and effort on it. It is now personal for them.
The entire situation will be a lot like a human relationship. The cliché phrase “the thing is about me, not you” has to become your guiding star, when you will be informing people that the project, you and them will be going separate ways.
Let’s see through some steps that may assist you a lot. You will need time to get prepared. Despite all the preparation you will get some unexpected surprises. Be prepared to be prepared. And flexible.
1 – 6 month before closing
- Inform your users of the upcoming menace. They also need to be ready. Make sure they find out everything just in time and won’t get the feeling they are being rushed or anything. The more time you can afford to spare, the better. But think of your business as well.
- Tell that there are lots more new possibilities open. The project that is currently closing is not all you may offer, right? You are developing new and cooler stuff, so point that out. That’s free advertising. Or at least encourage them to export all their data.
- Disable the possibility of new registrations. If more and more will be coming that will simply make things worse. I guess I don’t have to explain this part, right?
- Quit all related marketing projects. They will be just a waste of money and effort.
- If you have a support line, keep it updated with all the project closure detail. You will be getting lots of questions from users and it will be rude to just ignore all their confusion. They won’t like it.
1 week to the end of the countdown
- Mail a reminder to everybody. The people used of forgetting will be grateful.
Today (the day of the closure)
- The final e-mail reminder before the grand finale. There will be those who love finishing their work in the final moment. Allow them to be aware.
All is done, and yet there’s work left. What needs to be done after the project is finally closed?
- Do you still owe users some money? Perhaps they have paid for a longer period of time or subscribed. Pay them back all the money that they’ve not used yet.
- URL, Mail, etc. The links, domains, mailboxes. Do you still need all those things, do you want somebody to manage them, or to dispose of them, or to have any automated responses of any kind? Consider all of your options.
- Close all legacy accounts. Twitter? Facebook? Google +? Don’t forget on your course of action with those. Want to keep them as memory, or to get disposed of them as well? It’s up for you to decide, just don’t leave them as they are. If you are keeping them – keep at least somebody for their management.
- .NET Development
- Banking & Finance
- Communities & Social networks
- Custom App Development
- Development process
- Digital Marketing
- Drupal Development
- E-commerce & Retail
- IT Blog
- IT News
- IT News & Trends
- IT Outsourcing
- Java Development
- Media & Entertainment
- Medicine & Healthcare
- Product engineering
- Project & Resources planning
- QArea inside
- Software Testing
- Start-up Development
- Technology & Innovation
- Travel & Hospitality
- Useful Tips
- Web Design
Go Community: The Best Golang conferences of 2018 (and a few to look out for in 2019)Read more
From Gaming Videos to Redefining Instant Messaging: Quinn Hu's Long Path to Serial EntrepreneurshipRead more
7 Reasons to Truly Love MicroservicesRead more
The Best Languages for MicroservicesRead more
QArea's Year: Summing Up 2018Read more
What's New in Golang 1.11: Release Notes OverviewRead more
Why You Should Start Learning Dart and Flutter Right NowRead more
Golang Vs Python: Which Language Is Best for AI ProgrammingRead more