Software Tools: Purchase versus Development

Few days ago Ray White with his post about buying versus building software components reminded me my very first post on the blog which touched the same subject.

Over a couple of years I’d add one more thing to the discussion. Remember what your core business is. Sometimes you can judge building software just for yourself basing on functional comparison and cost analysis. However before making a decision go deeper.

Think if that would bring your company forward? How much effort you’ll need to maintain that piece of software. How many projects you won’t be able to handle because of building software tools inside. What’s the alternative cost?

I think over time I evolve more into “leave it to professionals” kind of approach. What is yours?

Don’t Be Afraid Of Small

At the moment we’re about 35 people here in Wind Mobile. We’re still considered as a small company. And sometimes clients still considers that as an issue.

Yes, I know, I shouldn’t be surprised, yet I am. At least partially. While I understand relatively small size of the vendor company brings some risks for the client it also brings a list of advantages which are usually underestimated.

Flexibility

Small is flexible by nature. If you’re small you much easier adjust yourself to environment. To ever-changing requirements. You’re much quicker when it comes to react for new situation. One of main big players on our market is known they never deliver any ordered change request in time shorter than a couple of months. Even if it takes them a manday. We are on the other end of the scale.

Cooperation

When you’re small you value relations. Since you don’t have loads of salespeople you sell via references. And you don’t have references unless your clients are happy with cooperation with you. Therefore you put much effort to improve the cooperation. Maintenance people like you. Product managers like you. It’s a win-win.

Engagement

Since each similar deal is relatively more important for small company than for a big one small organizations usually care more. If you don’t have comfort to be able to trash a project with almost no negative consequences for the company your level of motivation will be way higher. You’ll just care more.

And yes, choosing a small company is a kind of risk but most of the time it’s a worthy play. I don’t say that just support my ego. I’ve seen much more failure projects delivered by big players just because the vendor failed in one of above criteria (usually in all of them).

Of course you can always bring the old motto “No one got fired for choosing IBM” but at least don’t try to state you choose the best option.

Great Companies

Do you like your team?

Can you ask your colleagues freely whenever you feel like it?

Would you feel supported if you wanted to change your profile within the organization?

Do you feel comfortable when you go talk about work issues with your superiors?

Do they listen to you?

Does your boss say simple “sorry” when he screws something up?

Did recruiters were completely honest during your interview?

Is there “one for all, all for one” kind of environment?

Have the most annoying thing changed over the past year?

Would you recommend the company to your friends?

If the answer is 10 times “yes” you probably work in a great company.

Culture of Innovativeness

Last week I attended a conference called Innovative Management. My friend commented “There can be nothing innovative on conference which has innovative word in its title.” I can’t say my expectations were much higher. Imagine people from big telecoms, big TV stations, big internet portals and big banks talking about innovation in their companies...

They will tell you about company culture which supports innovation. They will tell you they have to fail sometimes on their road to innovation. They will tell you about setting goals to people and letting them to find the way how those goals can be achieved. They will tell you how much time of their teams spend on innovation.

Bullshit.

I’ve seen there several of those companies live. I’ve worked or work with them. They’re our current or past customers. I’ve seen their teams. I’ve been working with them. They show nothing of above values their CTOs, CEOs and VPs are talking about. But they perfectly now how to play it safe. Procedures, ass-protectors, beaten paths. Creativity, risk and accepting failure (from time to time) aren’t on the list.

Top management from big companies is completely disconnected from people working in their companies. OK, they know how their firms should act to be innovative but do nothing to implement it down there in their organizations. I was shocked talking to people from fairly small company (a couple hundreds of people) which has exactly the same problem. I can bet they don’t know what problems their most creative people have. They don’t know about the rest of people problems either, but that’s another story.

To be honest I don’t know how big players deal with that problem. I’d love to see Steve Jobs not when he gives presentation prepared for weeks but during his everyday work. Google tries to flatten company’s structure and so far it works quite well. Microsoft became fat and lazy several years ago, so they’ve failed already. Anyway, I don’t know the recipe for big companies.

My recipe is a small company. Then that’s super-easy. You just know how your people work. You know if they’re playing safe or rather trying to improve their project or product. You co-decide how they’re promoted for creativity and how they’re punished for failures. Sure when you grow it’s harder and harder to keep an order and you need more formalism, but as far as you work in small company exploit your chances to be quicker and more flexible. Big players won’t catch you. They just can’t.

Prestige of Quality Assurance

The other day I’ve heard that old rusty idea:

“We should hire a bunch of youngsters as testers. If they’ll appear worthy and will be smart maybe (but just maybe) they should be offered a development job.”

No, no, no. Not that way. Quite the opposite. If a developer shows his worth, maybe he should be offered a quality assurance job.

1. From the best quality engineers I know, almost all have programming background. Even when they do some black-box tests they understand how software is constructed which makes their job much more conscious.

2. Testing is still very often considered as clueless clicking on the application waiting for the crash. The whole set of quite interesting tasks in the area of quality assurance is somehow forgotten. Load tests, performance tuning, tracking down architectural limiters in application growth etc. All of them more interesting than adding yet another edit window in yet another database application.

3. A number of boring tasks ascribed sometimes to testers are rather developers’ duties. I’ve heard: “Maybe testers would develop some unit tests for us.” What? Who? That’s developer’s job, isn’t it?

Yes, I know I’m dreaming. Unfortunately quality assurance roles are considered as worse ones. People understand promotion as moving from quality assurance position to development, (almost) never the other way. No one think for a longer while about details, the whole thing usually ends up after comparison of prestige brought by both positions.

I will still start discussion whenever someone will come with any idea considering testers as a worse kind. I think there’s a bit of truth in saying that developers treat themselves as sacred cows too often, but to be honest one of main sources of having the situation alike are managers who don’t appreciate testing roles, considering them as low-budget options.

As far as decision-makers attitude won’t change there won’t be much difference in that area.

Definition of Success

When I was thinking about software success stories to add my piece to recent meme one particular project came to my mind. Actually it had nothing to do with my influence on its result so it didn’t suit to the meme, but still I thought I’d share it. I consider the project as a success although it’s rather far from a classic example of well-crafted piece of software driven by a committed team of seasoned professionals. It was a bug tracking application which my very first employer had developed for their own projects.

Several information about Track, which was the name for the application (very creative name, indeed), shows it was far, far away from perfection when it comes to judging project/product management and software development processes.

1. Track was both proprietary and legacy project almost from its birth. Language it was written in (Clarion – yes, I know you consider it more as car audio manufacturer than programming language) fits well to the picture.

2. The application was treated as a putrid egg among developers. It wasn’t a core task for anyone. It was always a sure-shot candidate to pass to a newbie developer joining the team. Youngsters didn’t know what a nugget was handed to them.

3. As the result, developers working on Track changed several times which ended up with no particular style of coding. What more, at least a couple of them were learning the technology while developing the application. A great idea to create an example how the code shouldn’t look like.

4. No one really could remind the real testing period for Track. Developer’s tests were enough. Testing is overrated anyway.

5. Flexibility and Track doesn’t rhyme well. Actually it doesn’t rhyme at all. The number of things which were hard-coded and assumptions made during development was really impressive, although I’m not sure if that’s something to be proud of. It’s hard to imagine any other company which Track would show usefulness for.

OK, great start of the story of success, isn’t it? The story lying behind Track’s birth was simple – company bought quite expensive bug-tracking solution which unfortunately didn’t appear as useful as it had been expected. As company was paying the rent developing software they decided to write something similar but with needed improvements added. The rest is pretty well described above, yet every issue or decision can be quite well-grounded.

1. Track was proprietary but no one ever wanted to sell it to anyone. OK, one of our parachute-CEOs had the idea for a moment, but fortunately the application was just un-sellable. It was legacy but actually that wasn’t any issue here as no one ever wanted to sell it to anyone. OK, one of our parachute-CEOs had the idea for the moment, but fortunately the application was just un-sellable. The programming language was than the most intensively used one in the team and no one ever wanted to sell the application to anyone...

2. Having newbies working on the project the chances were good they had some time to spend on their non-core tasks. With seasoned developers it wasn’t always so obvious. And despite their opinion about spaghetti code and strange ideas with implementation it was quite a good lesson for youngsters what they could meet in the wilderness out there.

3. As far as the application worked somehow (it could be magically even, no one would complain) it didn’t really matter what the quality of code was. The goal was to make things done, and they were done indeed. Why bother?

4. Track was used in production so we were testing it everyday. And there were two categories of bugs: those which annoyed you so much you were able to convince the developer to fix them or those which you got used to and live with them. The former, as the definition tells, were fixed. And somehow being a director of the team you could submit much more issue to the first category. Strange.

5. The application wasn’t flexible but it suited to the very company extremely well. It was like a glove crafted especially for you. When we wanted some functionality to be added it was added. When we wanted to do some usability improvements, nothing easier. Everything under control, here and now, just for a couple of hours of development and another couple listening to rants of lucky developer.

The whole project was actually nothing close to whatever you can read about either proper software development or proper project management. However year after year I appreciate Track more and more. I’ve worked with several different bug trackers and neither one was able to deliver user experience on the same level as the good old Track. It wasn’t by any means a great application, trying to migrate it to different environment would be like a wild-goose chase, but in that very company that very project was a success.

It’s the definition of success or failure which can change the project from one to another, so don’t be too fast calling the project either one.

Improvements Process

I had quite an insightful discuss today. One of those days when you stop for a moment to look at the point where your organization is. These are very valuable moments because for a moment you leave everyday approach (we’re fighting hard to complete the project; we’re improving that because it was all screwed up) and try to judge with no bias how things really look (we’re doing fine work but the project is still a piece of crap; improvements are huge but we’re still a hundred years behind the third world).

While typical mindset focused on the flow and those little improvements you do is essential to make constant progress, those flashes of true sight are needed to properly set directions of the process as a whole. While you can be happy with team performance and result of their work in a given situation, it doesn’t automatically mean all is set up properly. The chances are good you will find many flaws if you look from a distance.

OK, you have improved your KPIs of resolution time overrun for submitted issues from 600 days in a single month to 3 days during half of the year, but what about software development process? Unit tests? Nope. Code review? Nope. Formalized quality assurance? Still nope. Don’t be so proud then and go continue your job, you have still much to do.

Improvement process is constant, that’s nothing new. However, we often forget to make a little stop from time to time, take a deep breath and face the tough truth: how far you are from the finish line and if direction you’ve chosen shouldn’t be adjusted. It’s a bit like sharpening the saw. Discussions with former colleagues can be very helpful in that area.

And yes, there’s still pretty darn much work to be done here.

Alternative Costs

- We can buy that control for 100 euro or we can develop it ourselves.

- How long it would take?

- A week or two.

- How do you think do we need the control in future implementations?

- So far we’ve always used different protocol. I guess this is one-time shot.

- OK, 100 euro is no money here. Let’s buy it,

- Hm... We have to wait for customer opening the tunnel anyway. Maybe we should spend the time to prepare the prototype. We’ll always have buying the control as a plan B if something goes wrong.

- Well... First, two weeks of any of those guys costs us more than a hundred. Second, think how much value we lose in things he won’t do during those two weeks. That’s not cheaper.

This time the situation was a no-brainer, but I think about others when someone forgets about alternative costs. Sure, you can spend months trying to win that deal investing a lot of time of both sales and technical staff and you’ll end up a runner up, which in case of bidding is a lose. Sure, you can take that project and engage the half of the team to finish barely on time rescuing the rest of not-so-impressive margin, maybe developers will have fun at least. Sure, you can spend long weeks developing your own implementation of that protocol, which was already done by other 561 companies although I wouldn’t bet it will either the best quality or the cheapest option.

Considering all those things as atoms, they can be easily justified. But remember – people engaged to those “projects” won’t do other work, which probably brings you some money. Your core projects can be jeopardized by doing a bunch of non-essential things. You’re going to take maintenance of all the new crap on your back with no repeatability asset making support engineers life a bit closer to hell than it used to be. These all are alternative costs. Things which can’t be easily shown in income and costs analysis, but are happening.

That’s why it’s often the best option to choose the “no go” option on the very beginning. If you have guts to do it of course.

Organization with Potential

There’s one thing which differentiates organizations with potential from those which are dead ends. It has nothing to do with the quality of the current system – it can be better or worse, doesn’t really matter. However, it has much to do with the way the company would change in the future.

The thing is:

The way the organization learns from its mistakes.

If your company/team/whatever is willing to take the lesson from mistakes which are made it’s worth to stick with it. Other way you’d end up with the same old shit you already have. Nothing special I guess.

Setting Deadlines

I came across a post from Bas de Baar about customers setting deadlines. Bas points Parkinson’s Law (work will fill all available time) and Student’s Syndrome (job can be done better when given more time) as the main fears which stand behind overly short schedules forced by customers.

I do agree with Bas with his distance to these so-called laws. I do agree that motivated, enjoyed team can deliver software earlier than planned, although from my experience I could probably count these situations on a single hand. However, I really don’t think the main reasons of having customers expecting software delivery by tomorrow lay in that area.

Fixed Deadlines

There are projects where deadlines are written in stone. The ERP system implementation which has to end by the end of the year, because migrating accounting data during the fiscal year is the worst nightmare project manager can dream of. Solutions for the biggest companies (like mobile operators) where dates of marketing campaigns are set quarters before they’ll be kicked off. Features whose development is forced by the change in the law. Components which integrate with external solutions being implemented two moths from now. In that case the customer will probably make fair buffer for themselves from the very last date, will give you your deadline and choice: their way or highway. And it has nothing to do with Parkinson’s Law.

Soft Deadlines

Another case is when there’s no such thing as fixed deadline. Vendor can deliver the solution on the date mutually agreed by both sides. Yes, one side will tend to shorten the deadline, another will tend to lengthen it and everything is a part of the bigger thing – closing the deal (with competitors right behind your back). If you often follow that scenario ask yourself: how many times deadlines were proposed by your side and weren’t kept? The typical situation is we boldly commit we can do it in three months or by Friday or before the 1st or whatever and then, magically, we can’t keep those dates, because we were too optimistic or have too little knowledge about the project or maybe... just maybe... it was the customer who forced tight deadlines. Ah yeees, you’re right, that was the case. Like always. That darn customer wanted it all by yesterday.
I think we have two different issues here:

• Ability to deal with fixed deadlines on both sides of the table. One of the main problems here is small pressure on signing the deal before date planned for that milestone.

• Ability to plan and schedule work on vendor’s side. A lot was written on the subject but I’m yet to see project plan which will go as planned.

And Parkinson’s Law? Maybe it is somewhere there in the back of the heads of customers, but its impact is really overestimated.

5 Harbingers of Software Product Failure

1. Lack of quality improvement. Another implementation and the same, not-so-high quality? Haven’t learned on your mistakes from the last quarters? Still hitting the ceiling with the application’s performance? Ops, it looks like you neither learn nor improve, but stand in the same place with your product over the time.

2. Constant, similar problems with finishing projects. Isn’t that fifth time in a row when deadlines are 100% overrun? Wasn’t that the last customer who was making the same problems with signing the final acceptance? Why all of them are so scrupulous? Oh, maybe getting things done (and I don’t mean 90% done) isn’t really as easy as you thought with that application.

3. No energy to overcome technology constraints. Haven’t we just mended that darn performance? Can’t we just do it right once and for all? How many times more we’ll hear about those darn technology constraints? Hey, try to take some time and plan (with details) what exactly you do need to finally leave known limitations in the past. And don’t be surprised with results – as far as you don’t cheat it’s likely to cost a lot of time and money.

4. Mediocre product placement. Have we just spent three quarters on that low-margin project? How come? Why losses when all projects looked profitable on the beginning? Can’t we have just a standard implementations instead of all those integration stuff? That’s just a guess, but maybe your niche requires all those integration work. That way unless you plan your projects to include integration work you’ll always underestimate the costs. What more, maybe your niche expects low price and you need a product which is well prepared to customization to sell it profitably.

5. Low level of stabilization in the team. Maybe it’s a good idea to use our R&D team in that implementation as the other free developers are fresh as grass during spring? How about hiring a couple of temporary programmers to make that one? Wouldn’t that be a great idea to outsource this part as we’re running out of resources? Hold on, I’ve heard investments in team competencies and knowledge pays off. I’ve also heard “every specialist can be replaced with finished number of students” paradigm doesn’t work as perfectly as it was believed. Maybe considering developers and project managers more like people than resources isn’t a bad idea?

Changing Business Model

When you start a new software business, you need to decide how to set up a business model. Where are your customers? How you will drain money from them? What exactly you’ll sell and what you’ll be just giving away for free? You have to name all those things unless you plan to be charity organization.

When talking about choosing a business model one thing is worth emphasis – the model you’ve chosen on the beginning will most likely change. Assumptions you’ve made on start will appear to be incorrect and the whole business environment (or rather your knowledge about the environment) suddenly will change. And, you want it or not, your business model shall follow.

You can quite safely assume that chosen business model will change. Especially when you run yet-to-be-established company, a microISV for example. Seth Godin mentioned that when he was writing about Squidoo outcome:

“What you start with is wrong. At least what we started with was. Fortunately, we planned on being wrong, and have revamped most aspects of what we built.”

The same thing we did with Overto. On the very beginning we believed people would be willing to pay for additional information we can provide. After service growth and analysis which people come and how they interact with the service we changed our approach much. For the moment we don’t plan to give paid functionality – all features should remain free in predictable future (which in software business isn’t very long by the way). The way we see environment we act in is significantly different. We’ve just learned much about our audience and it wouldn’t be the best idea to keep the old track with that knowledge.

By the way the actual business model is a subject for another post – I hope to reveal a bit of that in near future on the blog.

Patience

I’ve just poured off my home-made apricot-liqueur to bottles. It took almost a year to produce a bit more than two liters of that noble beverage. You can’t shorten the process, at least not when you expect good results.

Exactly the same situation you’ll find when you implement reorganization. Even the best-planned reorganization, which is well-designed and needed, takes a lot of time to show its results. The most boorish case you’ll find with lay-offs. Any savings can be made after some time (usually 3 months in Poland).

However the schema works universally. You’ve had the idea. You’ve planned everything. You’ve even convinced the decision-makers to your plan. And somehow it takes long months to implement all those great ideas and quarters to see results. You expected them right away, didn’t you? No, no. Not so easy. Do your job day by day until you see the light in the tunnel.

It’s exactly the same like with making liqueurs – you need to be patient. The best recipe won’t bring the results quickly just in sake of using it. It will test your patience. You can have it fast, but you’ll have it poor. On the other hand you can have it outstanding, but you have to work with consistence and patience.

And the results are usually worth waiting.

Technology for Web Applications

If I was about to start a new software project it would definitely be a web application. A couple of years ago I was building a team creating ERP solution from a scratch. If I had to choose one thing I’d change if I had a chance to start whole thing once again I’d go on-line instead of creating a classical desktop client. And yes, I remember that two years ago web technologies wasn’t so mature they’re now, even though I wouldn’t actually call them “mature” yet. On the other hand now, after two years of following that path it would be a great advantage over competition. Especially when we talk about SME segment of market and multilingual application and that was exactly our target market back then.

When I think about that and I recall all those users I had to deal with when I was support team manager in CDN XL team I believe we’d have to address all major web applications issues. OK, maybe graphical design wouldn’t be so crucial, but speed, contexts, and keyboard-driven steering were on the list. The technology should have been chosen carefully.

A little side note: time when I was an active developer is rather ancient, so I my look at technology is based on what I see developed by others. I don’t say something is definitely impossible with any particular technology, but I believe that there have to be some reasons why (almost) no one makes very good/great applications using the technology. Another little side note: when I look at application quality I consider several factors independently, so I can imagine e.g. great usability combined with poor functionality. Of course overall outcome won’t be very impressive that way.

Coming back to hypothetical technology choice on the end of 2004 I would probably opt for Flash. It loads long, but that’s a single time investment. After that it can work instantly. In terms of speed, when something is efficient in games it will be enough in business applications too. With fully controlled working area, made entirely from your own “controls” contexts shouldn’t be a great problem. I don’t say it would be easy, but I guess there’s no serious technical barrier to achieve that. You could also ignore standard keyboard shortcuts from browser – you wouldn’t have much use of them anyway. A great graphical design wouldn’t be a problem either.

I don’t say that from the technical perspective it would be easy. You don’t see many business applications made with Flash around. The alternative is placed in different AJAX technologies. However, when I look at AJAX applications, they never let me forget I’m using the web. It does mean that despite having all advantages on-line apps provide out of the box (collaboration!) they lost competition in usability category.

I haven’t seen any Flash Application Framework, but I guess we’ll soon see one. The other way is to find universal solution of usability issues in AJAX, which is far easier to use than Flash (basing on number of existing applications). If I had to bet I’d probably go for the former solution, although it can look as a weird idea.

Web Applications Flaws

I believe that the future of software is the web. If you read me regularly, you probably aren’t surprised here. However it’s still hard to imagine the world without desktop applications yet. Why? Although network access isn’t on the availability level of power access (everywhere and always) it’s already acceptable for software except mission-critical applications. The main issue is different. The main issue is usability.

Web applications are still much less usable then their desktop brothers. I’m not talking about functionality, which can easily be enhanced, but about the way the user interacts with the software. There’s list of flaws web applications experience.

• Speed. The Mythical Google Speed, which is by the way still unreachable in rich web applications, doesn’t stun when compared to typical desktop software. On desktop all simple things, like menus to take the first example, work instantly. And I haven’t heard about anyone being impressed by that.

• Contexts. Take the web app. Use the right-click, The God of Context Menus. It will open the context of either browser or Flash Player. Definitely not the context of application.

• Keyboard. Web sites are designed to work with a mouse or a stylus, not a keyboard. On the other hand people are designed to work faster with the keyboard. Web applications very often lack things like shortcuts, which allow better interaction when you’re an experienced user. By the way, there’s another trap here – should Ctrl+F open the application’s search engine or rather the one from browser? When to override browser’s shortcuts and when to leave them in charge?

• Graphical design. I think that’s another great invention of web world. People prefer nice applications over ugly ones. Yes, new, cool, Web 2.0 applications are much nicer than we saw several years ago. However, they all fade when compared to new, cool, Desktop 2.0 programs. Last week I could play with several pieces of software developed with use of WPF and now I’m twisted – Google Reader isn’t so cute any more.

A couple of things can be corrected with current technologies. Microsoft Outlook Web Access has great context menus for example. And, if I’m correct, it’s since 2003. It doesn’t automatically make it a great web application however. Still, people choose the web version only when they have no other choice or in areas where desktop Outlook really sucks (with poor network connection it takes ages for Outlook to stat synchronization with Exchange server).

Yes, we choose (and will choose) more and more of web applications, but in terms of functionality and usability they’re usually worse. Somehow we can lower our expectation, only because the software is installed somewhere else, not on our PC. That’s the subject to play with for psychologists I guess.

Future of Software

I came across summary of Hasso Plattner’s presentation about innovation. His main point is that SaaS is the future of software (no surprise here) and he references often to Google. Google SaaS success. Google speed. Google minimalistic form. Google this. Google that.

While I agree with many of Hasso Plattner’s arguments, I think he flatten the case of Google. Sure, Google speed came into software development dictionary, but it’s a feature of the search engine, not every Google application. Sure, pure design works perfectly, but another time – for search engine. GMail, Google Reader or Google Analytics have rich, webish 2.0 design.

Google is a flagship example of SaaS success, but depending on product there are different priorities in design or innovation. Pure form and speed of Google search isn’t copied in many of other applications. And you can’t treat search engine or AdSense (which is similar case) as typical SaaS applications. Much better examples here will be Reader or Google Docs which are designed to be richer, nicer and (of course) slower.

Although I'm a big fan of on-line software, I think there's still a significant big gap in usability between desktop applications and their web brothers and sisters. I'm yet to see web application which will be fast, functional and full of features. That's the SaaS future, because it will allow smooth migration of users from desktops to web terminals. In other words, I'm pretty sure that we won’t be ruled by minimal design as the price paid for on-line speed. Web 1.0 to Web 2.0 path shows that people want nice and functional UI.

How to Choose Bad Strategy

I guess you won’t find many questions like above around. Although sometimes I think those strategy-creators up there would use some of these. Not so long ago I wrote how bad strategy labels had chosen trying to kill internet radio stations. It wasn’t much later when I saw this appeal on Pandora:


Today RIAA won another skirmish. Pandora welcomed me with the message:

“We are deeply, deeply sorry to say that due to licensing constraints, we can no longer allow access to Pandora for most listeners located outside of the U.S. We will continue to work diligently to realize the vision of a truly global Pandora, but for the time being we are required to restrict its use. We are very sad to have to do this, but there is no other alternative.”

Congratulations guys, I guess you’re much closer to Pandora’s death. The problem is you don’t see that your strategy is just a lengthening of your agony. Instead of supporting ideas, which would allow you to exploit new possibilities, you try to kill them. You’ve already killed Napster's first life but, be honest, had it changed anything? Kazaa, BitTorrent, eMule and whatever-is-the-coolest-p2p-now came instead. You could have been a part of the new business, but you rejected transition. You stay in your castle waiting for flood which is coming fast. Instead you could have had a nice ship by now. Now you dismiss another chance. What a strategy! I’m impressed. Really.

I prophesy death of labels and incarnation of Pandora-like services soon. By the way last.fm still streams the music to Poland. Another enemy to hit? Nevertheless, if someone wants to follow the way of labels and RIAA I have several advices.

• Don’t look forward. If something works now it will forever.

• Look back. Analyze your past strategies. There are true pearls. Don’t listen to moaners, world hasn’t changed so much to reject ideas which were successful in seventies.

• Don’t look for partners. Especially small ones. Especially new ones. Your only possible partners are companies like yours. Hey, they understand you perfectly.

• New ideas are bad. They always endanger your business. They’re never a chance.

• Stay. If you make bucks it does mean you’re in good place and moving somewhere else wouldn’t be wise.

• Don’t accept what you don’t understand. It would be even better to kill it. Leaving it alive is unnecessary risk. The law is probably on your side... yet.

• Pretend there is no Internet. Hey, people lived without the web 20 years ago so they can live without it now. I guess.

Sometimes when I look at companies’ strategies I think many of those rules are followed. When I look at labels they are all compliant. I take a pity on people like Tim Westergren who have to pay for labels’ politics.

Try-and-Buy and Fair Price

Several posts ago I was advising to consider or reconsider a business model even when you’re an established company. A thing which experiences its renaissance these days is try-and-buy model of sale.

It became popular with shareware, when you had either limited features of the application or limited period you was allowed to use it. Nice idea, although not working perfectly. It was always a tough decision which features should be turned off to encourage users to pay for the application. On the other hand there were a lot of different hacks (not quite legal of course) which could overrun your protections and make freeware out of your shareware.

Nowadays, with moving your app to the Web it’s not an issue any longer. When you host the application you can turn it off any moment. Now, trials earned another meaning. You don’t need to limit features any more. You don’t have to fear about stealing your software. You can give it all for a month. If someone like it she’ll buy it.

When talking about selling, the Web gives you even more. With the on-line application you have a control over the whole installation and you don’t need to sell it once for a big bunch of bucks. You can set the fair price, paid monthly, for your services and take advantage of low maintenance cost per user. Customers won’t take away a piece of software they’ve bough leaving you without even a support fee simply because there isn’t any “piece of software” any longer. Now it’s a service, not a product.

The examples of combined try-and-buy model and fair prices come from everywhere. Emusic.com charges fairly for its content and they have of course a try option. 37signals gives 30-day trial for all of their applications. Want to buy? Aren’t sure? Go and get some. You can leave it you want. No money needed. At lest not for the first month. Another example: FogCreek with 90-day money-back guarantee (no question asked). Lately FogCreek user used chargeback for the first time ever. Ian Landsman with his HelpSpot uses the same approach. Try-and-buy model pays off in his case too. That’s just a bunch of examples, but the list could be obviously much, much longer.

Try and buy with fair monthly fee is the business model which become popular recently. It’s fair for vendor. It’s fair for user. A typical win-win scenario. That’s why the combination is so successful.

Choosing a Business Model

I’ve heard recently some bad news for internet radio stations. I guess it’ll end up either with closing internet radio stations or, most likely, having all of them moved to some kind of internet paradise which can’t be controlled from US.

I don’t get it. Instead of exploiting new, fast growing market they’re trying to kill it w before the birth. Don’t they see that people won’t start buying tons of audio CDs even if they were successful with destroying all internet radio stations (which won’t happen by the way)? It’s like saying “Hey, it worked 10 years ago, why it shouldn’t work now?” It’s like closing eyes and pretending the sun is shining on midnight. Hello guys, the world has changed.

Now with all this Web 2.0 buzz and constant migration from desktops to web applications, everyone, when starting a new project, should seriously consider this business model. The application no longer gives an advantage only for the sake of just having it. You need to give something different, easily accessible and, with more and more competitive market, you have to price it fairly. As mainstream record labels grouped in RIAA example shows it’s not impossible that you’ll have to redesign your business model even when you have a leading position now.

If I was about to start a new software business now, it would be definitely a web-based application. It gives you a bunch of options. You can sell your services for a monthly fee. You can earn your money with on-line ads. You can build the user-base in the long run and then sell it as the main asset of your service. You can build some unique technology, gain some activity to prove you’re better and then sell it to the bigger player on the market. You can mix all of those creating something new. There many possibilities with the Web and you’re not limited with standard old-fashioned business models.

Sure, if you’re a big player you have quite different perspective. That entire Web 2.0 buzz isn’t a good message for you, unless you’re Google of course. However, in this scenario you’re a desirable partner for many web start-ups. Just like Pandora, which needs to cooperate with record labels. Just like in my start-up – Overto – where we cooperate with internet auctions platforms: Polish branch of eBay and the biggest player in Poland – Allegro (Polish links only). Sure, you can say that you don’t want to see any “competitors” around and try to kill a bunch of them – that’s the way RIAA tries to do right now. On the other hand you can exploit chances young wolves offer you. Some additional income from internet radio stations if music is priced fairly. A lot of affiliated services add value and sometimes gives even better functionality than base service. E.g. we search through Allegro better than Allegro itself.

In every case the business model and cooperation policy, which I believe is a part of the business model, is very important for the future of organization. Even when you’re now fat and lazy it’s not give for a lifetime.

Chaos Report 2006

David Rubinstein from SDTimes gives us a little preview of last, yet to be published, Chaos Report 2006 from Standish Group. Although numbers have improved I wouldn’t say they are anywhere close to where they should be. OK, we have two times more successful projects than 12 years ago. Wow. It’s still only one third overall. And the figure I’d like to know (but is not published in the article) is how many projects delivered 100% features they had intended to? This statistic is also a part of Chaos Report. Back in 1994 it was less than a half of projects labeled “successful” with pathetic 7,3% doing what they should do.

Yes, we are improving, that’s for sure. If we keep our pace I’ll probably see more than a half successes in projects before I become a grandpa. And successful project would look like a car without two wheels, if I’m lucky.

Coming back to the Chaos Report 2006, thing which doesn’t change significantly over all those years is percentage of projects with time or budget overrun. It still oscillates around 50%. It means that you’ll face this kind of projects by the way. But it also means that there’s common approval for overrunning deadlines and budgets.

A couple of examples. One of our biggest customers, after choosing our offer was delaying the moment of signing the agreement for almost two months. Deadline remained unchanged and when we tired to move it further explaining that project start date was changed, we faced holy indignation. That way we formally lost almost the half of the time planned for our work. Of course we couldn’t make it and we slipped two and a half months and, what a surprise, it wasn’t a major problem. That way, it was perfectly OK.

Another customer asked for offers for some video solution. Deadline for submitting the offer was really tight, because they wanted to implement solution within a quarter since request for proposal was issued. It was May 2006. Few days ago we found out that they haven’t even chosen a vendor yet. What a rapid process. I’m stunned. I’m also happy that we haven’t gone through to the second round.

I guess you see it every day. You see deadlines impossible to meet or those which no one really cares about. You see salesmen who agree to promise impossible things just to get the deal. You see development teams constantly lied about project dates. How can you expect that number slipped projects will be shrinking? I believe Chaos Reports will show constant improvement in next years. Slight improvement. To see a significant change we’d need a mental change, which I don’t see actually happening.