Tag Archives: sustainability

Determining Ideal Release Frequency for Software Products

One of the questions product managers are constantly asking themselves is, “How do I get product updates into the hands of my users at a speed that is most beneficial?”

In 2011, I was a part of an industry that shipped software annually. All the companies in the industry were trying to figure out the best way to schedule their annual release to maximize the market splash. Should we release just after an industry event? Should we release just after the market share leader’s annual release? Should we release right after the board meeting? Should we release at the end of our fiscal year?

Over the last five years, many industries have shifted to more frequent releases, like quarterly, monthly, and weekly deployments. New deployment technology and hard work from DevOps teams have made it a different world for releasing software products. But it’s still a rich source of debate within organizations: what is the right cadence for your product(s)?

Pros and cons of shortening your release cadence

Pros Cons
Faster, predictable delivery of features and bug fixes Less time for you to squeeze in a feature or bug fix
The risk of a bad bug is lower in a smaller release Software bugs being released every 2 weeks will seem worse than if the same amount went out once a month
Faster feedback for the team More frequent meetings and shorter sprints mean a higher tax on the product manager/owner
The marketing, training, etc. teams have fewer items to cover when summarizing the release Release summary processes might need an overhaul to support more frequent releases
A shortened release cadence can be treated as an experiment There may be development costs associated with increasing the release cadence, like changes to the way the product gets updated

You’ll want to do the same sort of pros and cons list for your product’s particular situation. When you do that, you’ll want to consider some product management best practices. Here are some best practices for release cadence:

  1. Make the release less risky by making it small. The goal: minimizing bad changes vs. maximizing good changes.
  2. Your release cadence is not a race. Don’t make the release small because you want to hold to a cadence that your business doesn’t actually require. For example, if your users use your product once a month, who will notice when you push to weekly releases?
  3. Consider your release health. If releases every 4 weeks are good, it doesn’t mean that releases every 2 weeks are twice as good. It’s important to look at past releases for technical risks, like a ratio of documented bugs vs. release size.
  4. Evaluate the value a faster release cadence will give to the users that use the product the most. Your power users will feel a change in release frequency the most. Will a faster cadence make them have to give feedback faster? Will a faster cadence help them do the jobs they’re doing better and faster?
  5. Put your executive hat on. It’s not only the dev team and the user that matters…make sure that release cadence is in line with your executive team’s expectations.
  6. Re-evaluate your release cadence every few months. The answer to how appropriate the release cadence will vary over time, as your organizational behavior and your users change.


Did I miss a consideration for release cadence? Do you have any stories to share on the subject? If so, leave a comment.

For more product management articles, read The Product Guy Daily. I publish it every morning.

10 Things Henry Ford Could Have Taught You about Product Management

I’ve been reading through Richard Snow’s I Invented the Modern Age: The Rise of Henry Ford, and I’ve found a lot of parallels to my work in product management. Below are some things you could learn about product management from Henry Ford.

 

  1. A product can be wildly successful without being user-friendly. The Model T could literally break a user’s arm if the engine backfired during cranking. Just watch how difficult it is to use: http://www.youtube.com/watch?v=n0hQh_Ej_34
  2. Find a blue ocean. Ford’s blue ocean was people who worked in agriculture. The red ocean for automobiles at the time was the rich, monocle-wearing type; Ford instead focused on the middle class and dominated.
  3. When you’ve done something better than your competitor, make sure everyone knows it. If Ford won a race in the early days of automobiles, everyone knew it. When Ford offered his workers a higher rate of pay, everyone knew it. He took every opportunity to tell you why his company and product were better.
  4. Talking about new features means you’re going to have to continue doing new features. New features were not important to Ford, because his product was already correct. The customers became trained not to request enhancements.
  5. Don’t focus on innovation for innovation’s sake. Experiment with new product design for months before you commit to changes. Consider lots of prototypes.
  6. Once you know how to do it, build it quickly and cheaply. Focus on the efficiency and sustainability of your product.
  7. Have a single throat to choke when it comes to your product. Everyone involved with Ford’s product could have an opinion, but Henry Ford was in charge of that product. Someone else wanted it redesigned? Henry Ford noted it, but change was his decision.
  8. Eat your own dog food. Ford drove a Model T, and most of his workers drove one, too. He let his wife have a more drivable car, but he made sure most people around him were using his product.
  9. Let people talk about your product if they want to. There used to be joke books about the Model T and how cheap it was. Ford didn’t mind; he let people who discussed the Model T be a positive force for his product.
  10. When you don’t know what you’re talking about, keep your big mouth shut. Ford didn’t understand that his big mouth often hurt his product. He didn’t understand what we know as PR, but you wouldn’t make the mistakes he made.

For more information on product management and UX, read the Product Guy Daily. I publish it every morning.

13 Factors to Consider in Adopting New Customer-Facing Products and Services

I’ve been looking at what organizations should consider when adopting new technological solutions, and it got me thinking. Which factors need to be considered in the research and implementation of new customer-facing products and services? Here is a checklist that you can go through during your evaluation of new technologies:

 

Security

  • Will new products and services pose any risk to data security? If a user were to log in and have her personal information compromised, this would be a disaster!

Stability

  • Will new technology solutions have outages? Many of today’s technologies are “up” for less than 99% of the time. Is this acceptable? Is there something else that users can use if the solution goes down?
  • And will they strain other technologies we use? Some software types “sit on top of” existing systems and occasionally cause them to go down.

Performance

  • Consider the performance for the product or service. Will users feel it is dramatically slower than Google or Amazon?

Functionality

  • Are the features going to be there on Day 1 or will users experience iterations to get to full functionality?
  • Is there broken functionality in the product or service? Ownership: whose problem is it to fix? Accountability: to what extent is it our throat that is going to get choked when there is a problem?
  • One-size-fits-all and one-search-fits-all: should search software work out of the box for 60% of users or 99% of users? Specialists may be alienated if the general search tool is optimized for laypeople (and vice versa).

UX

  • Is a new technology-based product or service going to change the UX of other services? Major changes to your online presence have major implications for users. Even changes that are seen as very positive by most will frustrate some.
  • For a potential product or service, at what point will UX assessment be possible? Can you do UX assessment before making a large investment in resources?
  • Will the UX for mobile users change?
  • Redesigning the user interface to incorporate a new product or service is risky, and most organizations avoid drastic changes. Look at the CNN redesign model…

2000:

2003:

2008:

2011:

2013:

Impact on employees

  • What will new technology mean for existing employees’ job responsibilities? Is there currently expertise in the organization or will new positions be required? For those affected, will their other job responsibilities be lessened or changed?

Collaboration

  • Will the implementation of new products and services open doors for collaboration with other organizations? Could nearby organizations share costs with us? Do we want to work with those guys?

Resource usage patterns

  • Will new products and services change the current usage of your organization’s resources? Will end users incur the extra costs?

Hosting

  • Where does new technology live? The days of organizations having to buy/lease/maintain servers are coming to an end. Software companies offer SaaS solutions. Cloud companies like AWS can cheaply offer huge amounts of virtualized space. Due to cloud computing, initial development investments can be $$$, instead of $$$$.

Organizational priorities

  • How do potential new products and services address your organization’s priorities?
  • What is a new technology’s impact on ideal of being green? Is there a reduction in data usage? Does the fact that someone else is hosting it make it green?

Sustainability

  • Will new technologies remain sustainable? Sure, we can afford to have them now, but what about ten years from now? If organizational priorities change in a few years, will we still be locked into supporting the product or service?

Scalability

  • Will new technologies be scalable as usage grows?
  • Will new technologies be scalable as the organization grows?

Getting the word out

  • So let’s say we did implement a new technology-based product or service…how would we tell people about it? What is the marketing strategy?

 

What other factors should an organization consider? Leave a comment!