Tag: software business

  • Lessons Learned: Startup Failure Part 2

    Last time I shared mistakes we made while working on Overto – startup which was closed down some time ago. Today another part – things we did right and are worth replaying next time I’ll be engaged in a startup.

    Setting up a company behind

    Setting a company, which is quite an effort in Poland, from the very beginning was really a good idea. All founders knew each other well so lack of trust wasn’t the main reason standing behind the decision. We just wanted to give ourselves a bit of motivation making it a real business. However thing we didn’t really plan was that we gained much credibility showing company’s details instead of letting people think the whole thing was created by some student during holidays and won’t be supported in any way in future. Seeing a company behind a service doesn’t guarantee you it won’t die but at least you can be sure someone cares.

    Long discussions before start

    Before launching the project we had very long discussions about what we plan to do and how we want to do it. Of course not every detail was checked but when I compare Overto to other startupish projects I was working on it was really well-thought at the beginning.

    Wide range of roles covered with our experience

    We had really good pack to run an internet service. Development, administration, user support – in all those areas we had experience from the past. There weren’t many things which could have surprise us. We weren’t forced to look for a specialist in any technical aspect of building our application.

    Working in the same place

    For some time we worked in the same building which helped much in decision-making process. We could all meet ad-hoc whenever something important had to be decided. After some time we spread among different places and suddenly we saw how much value was in working in the same office.

    Despite we invested some money to fund the project I don’t treat it as a loss. For experience I gained it was a low price. Another time when I’ll decide to jump to that kind of project chances of success will be bigger.

    First part of lessons learned from startup failure

    Whole Entrepreneurs Time series.

  • Lessons Learned: Startup Failure Part 1

    Some time ago we closed down Overto – startup I was involved in. It was a failure – pretty obvious thing since we’ve closed the service. Since we learn much on our mistakes I think a reliable analysis why the business have failed should be valuable for you. For the beginning things we screwed.

    No one working full time

    From the very beginning we knew none of people engaged is willing to leave their daily jobs to commit fully to the startup. We thought we’d able to run internet service after hours. To some point that was true. As far as nothing bad was happening with the servers and the application it was all fine. We were working on new features when we had enough free time. Problems started when we faced some issues with our infrastructure. We weren’t able to resolve issues on the fly and had several downtimes. You can guess how it influenced user experience. That also backfired on service development since we had to focus on current problems instead of adding new functionalities. Lack of person working full-time and being able to deal with maintenance and bug fixing was the most important reason of failure.

    Catching the market

    That’s partially a consequence of the previous point. Since we spent majority of our limited time on trying to keep the service running we weren’t able to catch the changing market. We needed to cover new areas to move the application to another level but we couldn’t complete ongoing development. The whole project stopped in beta version and for users it didn’t look like anything was about to change.

    Lack of marketing skills

    Thin line between life and death of internet service is a number of users. For the initial period of time the numbers were growing systematically. Then we hit the ceiling of what we could achieve effortlessly. It was a time to do some marketing. Unfortunately no one of us was skilled in that area. Even worse, no one had enough time to fill the gap. That would be another stopper if we dealt with the problems mentioned above.

    Business model

    We hadn’t checked very well a business model we set up on the beginning. We were surprised a couple of our features weren’t as unique as we’d initially thought. Ironically that wasn’t a big problem since we had a bunch of ideas how to adjust the strategy in a new situation. Anyway, you should plan to change your initial business model.

    Screwed chance of selling the business

    After we’d decided we won’t be able to maintain the service in the long run we had a chance to sell it. To make a long story short we screwed negotiations starting with way too high price. We thought more about how much work we put into the project than how much it can be worth for potential buyers. Things are worth as much as one’s willing to pay for them, no matter how long it took you to produce them.

    Waiting too long with final decisions

    I think that one is a bit sentimental. Since the service was our child we were reluctant to make a decision about closing it faster and limit losses. We’ve been tricking ourselves thinking that everything would be fine while we couldn’t get the application back to work properly.

    Second part of lessons learned from startup failure

    Whole Entrepreneurs Time series.

  • Good Enough

    My friend asked me to give an opinion about design of application his company had developed. I took a glimpse on their technical presentation with a lot of screenshots. I must admit my attitude was very positive, whole thing looked professionally. That’s what I told my friend. His answer was a bit surprising as he said he would have worked more on UI design. On the beta stage? It was really good enough. Or even better enough.

    The discussion brought me to think about good enough paradigm in software business. One side believes that if software is good enough the job is done. Another wants to polish all the details until they bring their software into perfection. Although I haven’t seen any statistics about that I believe the former group is more numerous one.

    Software constantly conquers new areas of our life including those where there’s hardly place for good enough believers. Hospitals, planes, cars or military areas. I guess you wouldn’t be happy if your good enough software managing your car brakes crashed. Yet still most software which is developed is not mission-critical products. It just sends e-mails, creates documents, pass information, manage some content, store some data etc. There’s a choice between good enough and close to perfection.

    Personally, I’m a good enough guy. I have just one point here. Costs. Imagine a theoretical scale of perfection of software ranging from 0% to 100%. When you start your development you’re in 0% when you finish you’re somewhere in upper half of the scale. On the beginning improvements are easy. You invite first test UI which looks like it was designed by blind monkey. Then you have first iteration of target UI. It’s a huge improvement, probably a couple of dozens percents on the scale. However, when you’ve already made several iterations with UI and it looks decent the next would be probably making extensive usability testing. It’ll take much more effort than the first steps. Results will be probably much less significant. Few percent if you’re lucky. Next step? Maybe user feedback? You employ a number of people, who deal with all e-mails and phones from users, than trying to find a schema in all that mess, then verifying if accidentally some requests are not exactly opposite to others etc. More effort. More money. Results limited. Maybe another percent earned on the scale.

    The example says about UI, but the rule is general. First performance optimizations will be fast and effective, unless you do them randomly. After some successes they’ll become harder and more costly. On the beginning of stabilization you’ll deal with big numbers of issues vastly improving stability of software. On the end the whole deployment will wait for a single bug fix. Of course that’s not a paradigm – there’re exceptions. Sometimes you can find some easy improvements even when you’re high on the scale, but it shouldn’t happen very often.

    That’s why I’m a “good enough” believer. I don’t refuse to make small improvements, even when users can live without them. They’re welcome as far as they’re cheap. Great example was described by Basecamp team. Those changes are close to border separating good enough from better (hard to say on which side they are), but they were quick and cheap. And I guess the more important improvements were done earlier. If the changes were significantly more expensive I think 37signals would leave it as it was.

    I believe that unless you have much time and money to spend you shouldn’t chase the ideal. There’re more important things to do.

  • My Biggest Mistakes

    Have you ever wondered what were your biggest mistakes in your professional career? Which things you should do another way or at least try to change? It’s usually easy to judge others, especially looking from a perspective of time. Hey, he shouldn’t have left the company then, because now he’d have been promoted at least twice. Easy to say, because it’s about him and you know exactly what happened during those two years after he left. Back then the decision probably didn’t look like a mistake.

    With the same schema we can judge our own decisions, however it’s much harder. First, for most of us it’s difficult to accept that we actually made a mistake. Second, it’s even more difficult to be unbiased when you consider yourself and your own actions. Nevertheless it’s worth a try.

    There’s one thing more – people usually tend to share with others their successes, not failures, so your own experience is even more precious – you have unlimited access to it. You won’t find a lot of “failure stories,” so I thought I’d share some of mine.

    Personal interactions

    When I was leading a support team I had a couple of conflicts with developers partially based on personal background. I thought that if I’m so dedicated and if I struggle to do my best everyone should too. It’s not so hard to imagine that it was rather naive point of view (we worked in a corporation then). Instead of letting other managers to resolve the problem with their people I was making my private tiny war. E.g. we did some performance tests to prove that one of developers didn’t make optimizations, just to show he’d ignored the task. Why didn’t I ask him if he had done that and spent much time for useless tests? Bah, don’t ask me now. You should have asked me then. I can recall several similar situations, all of them having source in my personal likes/dislikes and resulting in, let’s say, not optimal business decisions.

    Building a team

    I was once a department director, building a team and a product from a scratch. By the way it was a great job. I think my biggest mistake then was too slow promotions within the team. For me it’s very hard to promote someone unless I’m completely sure she’s the right person. However I should overcome my resistance instead of waiting too long before official promotion for a couple of the leaders. Not mentioning that I didn’t even thought about potential successors of any of the leaders. Subconsciously I tried to direct my people through the way I passed once: first informal role of leader with real manager controlling whole team and then eventually getting own team and formal managerial role. Unfortunately, I and one of my colleagues changed the job leaving over a dozen of people with no junior and middle management. The promotions were soon carried out, but with people rather unprepared to managerial role and little supervising it wasn’t a vast success. Some time was wasted too.

    Communication with sales

    As a manager of operations team (development, implementations, quality assurance and project management team) my biggest mistake was poor contact with several sales people. I know there’s always a conflict between sales and development, but I’m far from thinking that the technical side is the one which is infallible. Quite the contrary, I even wrote that in general it’s better to have a business person as a CEO and sometimes having a geek as a leader of a company isn’t a great idea. I know all of that, but still I haven’t managed to be on good terms with few sales. And by now I still don’t see how I could get it done right with those people. I’m not even sure if it was possible. Maybe more time has to pass and I’ll find out the answer then. Maybe our characters are too different and we hadn’t even a chance. Nevertheless, the fact remains, it’s my failure too.

    Choosing an idea

    I was working with my friend on a piece of software. Whole thing was intended as a micro-ISV idea, but none of us decided to leave everyday job. In this case our biggest mistake was choosing an application we worked on. It’s not about a market for the application – I still believe we had a chance. It’s about our attitude – we had little fun while working on the software we’d chosen and we reached the point where none of us was still motivating himself, not mentioning about motivating a partner. The software died unfinished. We’d chosen the application only because some of work (part of the code) was already done, so we thought it’ll take much less work to finish. Now I think we had about 5% of work completed, so the choice wasn’t a well-thought one.

    Depending on situation my mistakes were followed by different consequences – in the first situation results were negligible, in the last example whole initiative ended up as a failure. It’s just a bunch of examples, but I can think about a list of others based on both my experience and my observations. Generally, it’s not shame to err – making a mistake once is an occasion to learn, but making the same mistake twice becomes a stupidity.

  • Almost Completed

    One of projects I’m contributing to is a micro-ISV service. Maybe it’s not the perfect example of micro-ISV, because at least several people are engaged. It’s not single-person business, but the basis is the same. Whole idea was in its origin a world-changing service (or close). The main person working on the idea is a guy who loves it and strongly believes that the service will be great success. The rest of team keeps adding new brainstormed ideas to current concept, keeping ourselves on fire.

    Just like most of micro-ISVs. Just like most of micro-ISVs which failed. I wrote some time ago that faith and will to contribute in the long run are essentials when trying to build a product or service as the micro-ISV. But that’s not all. Another factor which is probably even more important is consistency.

    I’ve seen different “micro-ideas” (like you can call micro-ISV’s ideas for products or services) which had potential at least to earn for themselves. I played my role in those projects as a co-author, as a supporter, as a user. Range of ideas was wide – from a very fresh look on Internet entertainment services to yet another communicator. All of them I can call (more or less) failures. None of them fulfilled author’s expectations in area of revenue, number of customers or users etc. Many weren’t even born to be shown to the world – they died during pregnancy.

    When you have your application completed in 90% it’s usually much less than halfway to successful release. And when you’re 90% completed all the fun is the past. You developed the most enjoyable and the most challenging parts of a code. You exploited all your creative ideas during design. Now you have to focus on boring little improvements of website. Now you have to force your creative soul to think how to make your customers happy instead of thinking how to enjoy yourself with the work. Now you have to fix all those unrepeatable tiny little bugs which allow your frustration to grow. Now you have to deal with The Boring Time. And if you allow yourself to become bored – you lose.

    90% of completeness is just the beginning of the road. In this case 90% finished often means 100% failed.