Posted in Uncategorized
Tagged Agile, Alicia Dixon, Best practices, Dave Mathias, development cycles, features, go-to-market, Larkin Plaeger-McCollum, Michael Hopkin, Michael Smart, milestones, Nadia Barbot, phased approach, phased delivery, phased rollouts, planning, prodmgmt, ProdPad, product launches, product management, product roadmaps, Robert Anderson, software, strategy, user-centered design, UX, Virgilia Pruthi
It was my privilege to be included in Reasons Your Outsourced App Project Gets Delayed (And How To Fix It), by Nidhi Shah of Arkenea. Check out the article to see what 8 product managers and project managers, including my product management friend Drew Bixby, have to say.
Posted in Uncategorized
Tagged Agile, Arkenea, communication in organizations, deadlines, development cycles, Drew Bixby, estimates, milestones, Mobile apps, Nidhi Shah, offshore teams, outsourced teams, planning, prodmgmt, product management, product managers, project health, project management, project scope, remote teams, software, video conferencing
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
Horizon scanning is a technique for detecting early signs of potentially important developments through a systematic examination of potential threats and opportunities. Product managers can use horizon scanning to analyze what features would mean the most given several different possible futures for the organization.
Using horizon scanning for competitive strategy. Let’s say that I have a successful mobile product, and I’m creating a 3-year plan for it. The biggest driver for what I do is how competitor x performs in the market. Also, there is a patent lawsuit against competitor x that has a lot of focus from the executive team in my organization. I identify 5 futures that may happen, and 7 features that I want to consider. Then, on the second row, I assess the likelihood of each of the 5 futures (1-3). Next, on the third row and below, I plug in values of 1-3 for each feature, and my spreadsheet multiplies the value by the likelihood of the future. The column on the far right is a simple sum of the other columns.
What I find through the above example is that competitor x’s performance is more important than the outcome of the lawsuit, and I get a really good analysis from the face recognition feature across all 5 futures. Click here for the Excel version of the spreadsheet above, and feel free to use it as a template.
Using horizon scanning for proposed laws or industry standards. Horizon scanning is really useful when you’re doing an analysis of an industry that has different laws or standards that are coming in the next few years. Examples: when Canada added a new email spam law or when Europe added a new cookie law. In most countries, you won’t know for sure whether the law will become official on the date proposed, so you need to analyze several futures. Futures to consider with proposed laws:
- Law implemented on time
- Law implemented later than expected
- Law struck down in court
- Clause x added to law
- Law canceled by government agency
- Another country adopts similar law
I hope you enjoyed the post. Leave a comment on ways you’ve used this technique, and how it helped. For more activities for product management, read the Product Guy Daily. I publish it every morning.
Posted in Uncategorized
Tagged competitive strategy, features, foresight, government, government policy, horizon scanning, law, legal policy, planning, predictability, prioritization, probability, prodmgmt, product management, product roadmaps, risk assessment, risk management, strategy