Archive of ROI Articles

Growth is a make or break measurement for products and companies.  Investment is often determined by expected value, which is based (in part) on expectations of growth.  When you create a product, there are aspects of growth – how many people can use your product, and how many people do use your product.  When dealing with a freemium business model, there are two elements of use - paid use and free use.

Read the rest of the article…

Planning by ROI.  Hmmm.  Isn’t that impractical?  In an econometric way, yes.  But you can still estimate the relative value of the capabilities / stories you’re planning for your scrum sprints.  The point is – don’t look only at value – also look at costs.  While “ROI” may be a poor choice of terms, “bang for the buck” is not.

You’ve got a giant backlog of user stories and product capabilities.  How do you determine which stories to implement right now?  By the estimated value of each story?  Pick the ones the developers want to build next?  How about picking the stories that maximize the ROI of the sprint?  To do that, you need to estimate both value and cost.  While remaining agile.

Business rules are often hidden in processes as hidden decisions.  Once you discover that hidden decision, how do you communicate the impact of exposing and managing the decision?

Your strategy should be driven by the needs of the market.  Becoming market-driven is critical to intentional product success.  But it is not enough to understand your market.  You have to sustain your understanding, and take advantage of it, competitively.

Is your product successful because you were lucky, or because you were methodical and intentional?

Do you want to build a plan where you are dependent on good fortune, or do you want to make your own “luck?” Both approaches work, but only one makes sense as an intention. Slide 3 of your presentation to a venture capitalist should not say “And then we get lucky!”

Learning how to write use cases can be tough, but it is simple compared to the balancing act of determining which use cases to write and how to manage the expectations of all the stakeholders that are involved. It can be a difficult balancing act to prioritize use cases to assure that you meet the goals of the business while satisfying the needs of the users.

You want your software to be used, not to sit on the shelf. You can’t achieve the ROI of your software if people don’t use it. And you can’t achieve the ROI of your software by forcing people to use it either.  Some will fail to achieve the benefits, and others will delay using it or refuse to use it entirely.  You have to make them want to use it, and you have to design the software for the users who must use it.  Otherwise, you won’t achieve the ROI.

I am a big fan of boxes and arrows, but this time, Jeffrey Davidson found a great article by Dan Willis before I did, and told me about it. Thanks Jeffrey! The article is about how to deal with the what and how of requirements and design – and it provides some really sage advice. But what got my attention was the lack of prioritization of requirements in his example.

We all know the story about the emperor’s new clothes. I’ve been thinking about prioritization and scheduling, and as far as I know, no one is promoting that we maximize value – they (and we) have been promoting that we do the most valuable stuff first. Doing the most valuable things first does not result in getting value the fastest. In this article, we show why not.