Tag Archives: organizational behavior

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.

Making Interdepartmental Communication Work with a Difficult Department

As a software product manager, I’ve worked in both welcoming and hostile environments for interdepartmental communication. The bad environments often have silos. Silos can promote misunderstanding, finger-pointing, personal conflict, and stereotyping. Trying just 3-5 of the following practices can turn inadequate, unfriendly interdepartmental communication into enjoyable, healthy interdepartmental communication.

 

Work for your organization; not your department. As much as you can, be the best value to your organization. That means breaking down unnecessary interdepartmental silos and establishing a cooperative environment.

If it’s especially hard to get together, start putting it on a calendar that you need to talk to them. Silos are enabled by physical separation and long periods of non-communication. Get past the silo-causing activities.

Avoid blaming others; it’s an easy tactic to use to come off as the one person who knows what she is doing, but it is often bad for your organization’s health. There are people who make careers out of pointing the finger at other departments, but those people often increase conflict within the organization. Don’t be the one who makes an entire department hate you.

If you perceive someone is a bully or a manipulator, avoid a confrontation as long as you can. Bullies are terrible for an organization, but don’t confront a bully unless you know you’re likely to win. It gets messy fast, and unfortunately, sometimes the bully wins. Organizations often have no idea what to do about their bullies.

Avoid using tough love on another department. Don’t say, “It’s the only way they learn.” I always avoid having a “sink or swim” kind of scenario for anyone I work with, because what happens if they sink?

Your department is not smarter or better than any another department. I’ve worked with people who have the idea of “don’t talk to the bozos on the third floor.” It’s hard to believe how common that mindset is. Even if a department has limitations or negative traits, it doesn’t mean that they aren’t capable of coming up with an idea that helps your organization succeed.

Talk to other departments in their preferred method of communication. I have worked with several people who avoided email communication at all costs. Email threads can spin out of control quickly with interdepartmental communication, but you’re still going to need to put things in writing sometimes. Likewise, talking to people verbally also has its limitations, but you’re going to need to have meetings sometimes.

Don’t dwell on the negative traits of another department. When you dwell on the negatives, you start to talk about that department’s weaknesses with others. Then that perceived inadequacy starts to become a self-fulfilling prophecy.

If someone in another department takes initiative in doing something in your job description, praise them for it; don’t treat it as a threat. While it’s totally understandable to feel threatened in this sort of circumstance, an awesome person rises above that feeling and supports the effort of that person.

Promote a two-way street of information sharing. Don’t just have those kinds of interdepartmental meetings where it’s a monologue. Plan to listen and have a discussion. If there are too many participants for a dialog, figure out how to promote dialog in another effort.

Don’t just tell people what they want to hear; tell them what is going to happen. I’ve worked with people who only said “yes” or “that’s a great idea” to other departments. When deadlines were missed or roadmaps didn’t include the request, it led to them feeling like they’d been duped. Tell the other department the real plan, and you’ll promote openness and trust.

 

Do you have other tips or examples of interdepartmental communication working? Leave a comment!

3 Principles for Making Your Time Spent in Meetings More Valuable

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!

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.

10 Consequences of Having Product Managers as Primary Testers

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.