Browsing Tag


Apple’s App Store: The Rise of Transitionware?

The iPhone 3G product launch has had the kind of hype (and reality) that businesses dream about. To date, there are well over 1M phones sold and over 10M downloads from the iTunes app store. Apple’s newest creation opens the door to new revenue streams, but also strikes a new balance of power between the application developer, the channel, and the user. Some of Apple’s curious design choices may also be carving out a new pricing strategy: apps that start free, then later move to a paid model – “Transitionware.”

If you have iTunes and an iPhone or iPod Touch, you can access the app store. There are thousands of applications across many different categories like productivity, games, and finance. Apple segments the offers into “Paid,” and “Free.” Paid apps can range from $0.99 to $999, set by the developer, and Apple takes a cut of the revenue. Every app has a 1-5 star rating, voted on by the users, and an open commenting system. Anyone can review or rate any application, even if they haven’t purchased the app they are reviewing.

During the first month of the app store, there was a proliferation of simple free apps: flashlight (turns your iPhone screen white for use in the dark), to do lists, lightsaber, etc. The reviewers tended to cut (some) slack to the free applications. For example, some reviews of the free game iGolf:

Good Game
(5/5 stars) by: Rubayath

Great game, it reminds me of my gf’s Wii, and hte best thing is, it’s FREE.

It’s Decent
(4/5 stars) by: The ace of hats

Amusing game for free. Increainly [sic] unrealistic. My high score is 520 yards. Hold on tight to the phone.

Paid apps got no such treatment. Some samples from the game iFish:

This is worse than just bad
(1/5 stars) by S.S.S. Truck Driver

This is worse than just bad. It seems to be unplayable. Dose [sic] nothing at all that I can see. And no instructions at all…Dont [sic] get it even if it were free.

This should be free
(1/5 stars) by chr1s60

Extremely boring and pointless. The game is too difficult and the graphics and display are plain and boring. The sound is ok, but aside form that there is nothing even slightly positive about this game.

If you review more of the comments, you’ll find many from people posting opinions about the applications who haven’t even tried them! It’s no surprise that people like free better than they like to pay. The average rating for the across the top 25 free apps is 3.96, for paid it is 3.70. If you are a business, how can you take advantage of the goodwill of reviewers who like free, and still turn a profit?

Avatron has a different strategy for their Air Sharing application. For the first two weeks, they are offering their app for free, before the price transitions to the normal $6.99. The result has been amazing – highly rated reviews, and they are the #1 listed app under their category in the app store.

Lots of companies have used try-before-you-buy strategies in the past, usually in the form of demoware or low-cost student licensing. Jott recently transitioned out of beta (“free”) and into production (“paid”). The difference is that Air Sharing is a fully functional app, and users who got in during the free period will retain their functionality.

In the app store, buyers are making impulse purchases based largely on the advice of other iTunes users. Because of Apple’s walled garden, the first place that most users see an app is in iTunes. If the app is rated low, it’s done before it begins, so the ratings of the first few reviewers count more than ratings of later reviewers. The average rating on the Internet is 4 out of 5, so anything less than 4 is a death sentence.

Avatron’s strategy is brilliant because it captures lots of positive feedback from users who are happy to get a “deal” on a free app and reward them with a 4 or 5 star rating (currently 4.5 stars). It builds hype because those users feel like they are part of the in-crowd who got in on a special deal early, and the ticking clock drives media coverage (“get in now before it’s too late!”) that you need for a launch.

The coolest part about this method is that it taps into OPT – Other People’s Time. One of the key takeaways from David Meerman Scott’s writing is that you are what you publish. Good advice, but I’ll take it a step further and say “You are what others publish about you.” You can never have as much street cred online as reviewers of your product have. Reviews have become so ubiquitous, it’s startling to go buy a product and not see reviews – you get suspicious. BazaarVoice has built a company around it.

I predict that many more companies will adopt the “transitionware” approach to launching software in iTunes. The power of the crowd demands our respect!

You Don’t Really Own Your Roadmap

Here's your sign!Sales people hate looking stupid. Unfortunately, we often put them in positions where they look very stupid by changing plans and roadmaps, which is our own fault. How do you keep the trust of your team when your business, roadmap, and customers are shifting in the sands around you?

There are lots of reasons that plans change, some good and some bad: the Market shifts, the competition makes a play, or the company dosen’t hit its goals and has to layoff developers, which pinch your resources. All of these create a refactor in your roadmap.

There are several tactics you can use to lessen the impact of changes to The Plan. I’ve written in the past about the importance of separating your Roadmap from your Release Plan. This simple change, and the cultural impact at the Executive level down to the developer level of thinking that “a product/feature on the Release Plan is locked in and cannot be changed” is huge. Remember that Release Plan’s mean that the product or feature’s release is imminent and committed – your Release Plan should never cover >6 months.

Also, realize that you don’t really own your roadmap. The best you can do with the roadmap is plot a general direction for a product or service, but when it comes down to it, the Market and the Business own the roadmap. The Roadmap is not yours; you are the steward of the Roadmap. I see products and companies fail all the time because they set their roadmap and expected the Market to bend to them; it doesn’t work that way.

One-off deals can also derail the roadmap. In a smaller company where there is immediate revenue pressure, the allure of a special deal that “just needs this one feature” is huge. Are you ready to turn down a million dollars in revenue? Most Executive teams are not. Be able to illustrate how any proposed feature or product changes to your roadmap delay or eliminate your entrance into new markets or buying personas. That changes the special deal conversation from emotion-based to data-based.

New Development VP’s also have a tendency to take roadmaps off course. The reason: they love changing technology architectures. I carry a cross on this one since I’ve been burned before, from a CTO who changed the team from Java to .NET…which meant retraining some developers, dumping other developers, and hiring new developers. We lost 12-18 months just spinning – it was stupid!

When you see the VP of Development pushing for a change in development platform or underlying technology, drill closely into the details of why. Most Dev VP’s aren’t dumb enough to say “it’s because it’s a fad” or “because I want to get quoted in CTO magazine!,” and they will come up with legitimate sounding reasons why the old platform sucks and we really, really need this new one. You need to provide the voice of reason – with today’s technology, you can build an adapter to and from almost any technology without having to rip up your entire platform. If it’s that strategic to change your platform, the company should be able to justify the expense of building a parallel platform next to the existing one without disrupting current development.

One type of project that can be completely immune to external forces taking them off roadmap is the open source project. Since developers in this model often develop for themselves and not for the Market, oftentimes they don’t care what their users are asking for. Other open source projects are more flexible to the wants of their Market and do adjust their plans.

What other reasons pop up for taking you off roadmap, and how do you combat them?

The Failures and Successes of Open Source Product Management

AntI kicked over a small ant hill last week with my post about the (lack of) Product Management being a fatal flaw to open source software. Both CNet and Linux Today chimed in, and that story incited some really good comments. Some of the commentators were gracious enough to continue their dialogs with me in more depth over email. It’s only fair that I follow on that post with some of the great points they made.

First, there was some confusion between Product Management and Project Management. Product Management is still poorly understood and inconsistently implemented in technology companies, so it’s understandable that lots of open source programmers may never have worked with a good Product Manager. Here’s an email exchange I had with a commentator (who asked to remain anonymous):

Paul: …maybe we’re talking past each other on the definition of project management vs. product management…

Anonymous: …I use them nearly interchangeably since all products result from projects. The problem I have in your posting is your blanket implication that development style makes FOSS management inferior….

…I disagree strongly that project and product mgmt are interchangeable terms. Product management is the discipline of discovering, documenting, and prioritizing user problems, it looks at the market strategically and seeks to understand where the greatest user pain is and (in commercial companies) which problems can be solved with the most profit. Project management is tactical scheduling, resource allocation, etc…

This leads to Point #1: The “Product Management Probem” is not unique or limited to open source projects. This is completely valid. You can easily point at Microsoft or other commercial software companies for examples of products that had poor product management and don’t necessarily solve a pressing need. The Pidgin example happens to offer a teaching opportunity in the FOSS world, showing that no person or model is perfect.

Point #2: Many commenter’s stated (paraphrased): “We don’t need Product Management, that’s for commercial companies; free software already has a method to determine wants and needs across groups of users – it’s called forking!”

Forking is when a developer decides to branch off of a project to create something different, usually withing the same vein and built on top of the work that has occurred to-date. In fact, there is already a fork of Pidgin called Funpidgin that exists just to give users back the features that the Pidgin team “took away.” I would say that forking is a very inefficient way to solve this problem, but a commenter smartly called me out on that point saying that unlike in commercial companies, open source projects are not resource-bound – they can afford to be inefficient.

The main point of the post, beyond even the Product Management topics, is that a FOSS project can have one of two primary goals: either the developers are creating for themselves, or they are creating for others. To create for yourself means that you recognize user input but don’t feel any obligation to take it since you’re building an application for yourself. If the user happens to enjoy it, great. If not – fork and make something you like.

If you’re creating for others, you should be interested in the wants and needs of your target user base. This might mean forgoing a “cool” or technically challenging feature like auto-resizing text boxes. Now that open source software looks, feels, and acts like many commercial packages, users assume that the application was developed with their needs in mind. If the application does not meet their needs, they feel justified in offering feedback. This is where the disconnect comes from: users who assume that an application was developed for them and programmers who believe they are building primarily for themselves. If the programmers are interested in working for a larger user base, a strong product manager could help them fill that gap.

What if when you went to to SourceForge, you saw a badge affixed to the link that told you if this was a for-developers or for-users download?

Who are we creating for?

At least if you understood this bit of information at download time, as a user you wouldn’t bother going to offer feedback to a team that isn’t interested.

Point #3: “FOSS projects air their dirty laundry for the World to see, whereas commercial products get to keep it inside their four walls.”

Yes and no. Yes, open source is out there for everyone to see. Don’t think for a second that just because a product is commercial that the tradeoff decisions those teams make don’t spill onto the Internet. Just look at Microsoft Vista for an example. Or Facebook’s advertising platform.

Point #4: “There is Product Management in open source today! See JBoss, Mozilla, and others!”

This is an important point that I’d like to recognize. There are companies and projects that are contributing PM to FOSS projects.

I’d like to thank everyone who participated in the discussion!