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
|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:
- Make the release less risky by making it small. The goal: minimizing bad changes vs. maximizing good changes.
- 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?
- 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.
- 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?
- 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.
- 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.
Posted in Uncategorized
Tagged Agile, Best practices, competitive strategy, development cycles, organizational behavior, planning, predictability, prodmgmt, product management, product roadmaps, project management, release cadence, release frequency, software, strategy, sustainability, UX
I have been thinking about the amount of time we spend in meetings at work, and how to increase that value. I looked at meeting time as if it were a product, and used marketing principles to increase meeting time’s value. Here is my philosophy on how you can make your time spent in meetings more valuable:
Make your available time scarcer.
- Fill your calendar with the tasks you hope to accomplish.
- Follow the lead of college professors; introduce your available time as your “office hours.”
Make your meeting presence more exclusive.
- Restrict your attendance to certain types of meetings.
- Restrict your attendance to smaller, more efficient meetings.
Make meetings you attend more effective.
- Require x days notice on meetings.
- Use the extra preparation time to come to meetings prepared with more information.
If you can use these principles to change your meeting experiences at work, and your organization allows you to do it, it’s worth a try. Do you have other suggestions? Leave a comment!
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.
- 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
- 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.
- 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.
- 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.
- 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.
- Once you know how to do it, build it quickly and cheaply. Focus on the efficiency and sustainability of your product.
- 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.
- 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.
- 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.
- 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.
Posted in Uncategorized
Tagged blue ocean strategy, business, corporate culture, features, Henry Ford, Model T, organizational behavior, prodmgmt, prodmktg, product management, product marketing, public relations, strategy, sustainability, usability, UX
Sometimes a product manager is asked to do things like testing to help software development processes. This is especially true for product management job titles like product owners, business analysts, product analysts, etc. What about when the product manager is the primary tester? Sure, there are reasons why it can be a good thing. First and foremost, it is a great way for a product manager to understand the product and how it is used. However, I wanted to focus on the limitations of this arrangement. I’ve compiled a few of the consequences that arise from having product managers as the primary testers. These include impacts on the development process, conflicts of interest, and impacts on the performance of the product manager.
Impacts on the Development Process
- The turnstile. Using the product manager as a tester is to have one person be the action person for too many parts of the process. You’ll be at the beginning, the middle, and the end of the team’s work. In this flow, the product manager naturally becomes a bottleneck.
- The weird smell. You’ll be less likely to investigate something that passes, but passes oddly (something’s not right). In an ideal world, an engineer or tester should investigate the weird smell. A product manager probably doesn’t have the expertise or the time.
- The importance of testing. Testing is a full-time job (usability testing, performance testing, load testing, security testing, etc.). Doesn’t there need to be a dedicated person doing this job?
- The stuntman argument. If you’re an actor, you may not want to do your own stunts because it takes away work from a stuntman. Same argument here: you’re taking away experience from a junior engineer.
Conflicts of Interest
- Pulled in different directions. Product managers should want to ship the product as soon as possible; testers should want to send problems back to engineers to ensure quality. Product managers who test face tough decisions on what is important.
- Scope creep. The product manager will have the ability to sneak in additional requirements to get it perfect. It’s always very tempting for a product manager to do.
- Perfectionism. Being the finder of bugs makes you more likely to delay a launch to address a defect. After all, finding and squashing the bugs is what a good tester does.
Impacts on Your Performance as a Product Manager
- Less time for your day job. You’ll have less time to interface with customers. Understanding customers is probably the most important thing for a product manager to do.
- Different mindset. Testing puts you more in the details, and less with the overall vision. Testing every day can shift focus away from developing the 3-year big picture, or at least developing the big picture with an open mind.
- One more way to be wrong. As the product manager, you’ll be the throat to choke for starting late. As the tester, you’ll be the throat to choke for the launch being delayed. Why open yourself up to more potential criticism?
What do you think about product management and testing? Leave a comment!
For more information on product management, read the Product Guy Daily. I publish it every morning.
Posted in Uncategorized
Tagged Agile, Best practices, Kanban, Lean, organizational behavior, prodmgmt, product management, product managers, QA, scope creep, software, strategy, testing, weird smell