Tag Archives: Best practices

Does a Phase 1/Phase 2 Approach Ever Actually Work?

Alicia Dixon and I interviewed 7 of our favorite product management colleagues on best practices with a phase 1/phase 2 approach. By that, we mean a scenario where a product has features A, B, and C in 2017 and adds features D, E, and F in 2018. How do you avoid getting in over your head? How do you convey this plan in a roadmap?

A special thank you to Nandini Jammi, who helped make the post stylish and clear.

Check out the post here at ProdPad: https://www.prodpad.com/blog/phased-rollout-strategy.

After You’ve Launched Your App: Keeping Users Engaged Past Year 1

I’ve asked some of my favorite product management and UX colleagues about best practices for keeping mobile apps successful and fresh past year 1. Read the posts or full e-book by clicking on these links and visiting the blog at UXPin…

Pt. 1: App User Engagement: Expert Advice from @tektalk, @ellenchisa, & @Li_Li_Dhttp://bit.ly/23qq2dN

Pt. 2: App User Engagement: Expert Advice from @AndreAtDell & @rcauvinhttp://bit.ly/1Wa8kfN

Pt. 3: App User Engagement: Expert Advice from @SchulteElena, @delizalde, & @Paul_Yokotahttp://bit.ly/1Tuaikp

Full e-book: App User Engagement: Advice from 8 Experts – http://bit.ly/1W8PXHy


Photo credit (balloons): Flickr – Nicolas Raymond

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.

Interview with The Product Mantra

I’m honored to be in ‘The Three Questions for Product Manager’ series. Here were the three questions The Product Mantra asked me:

  1. How do you see the role of product manager evolving in the world of Mobile Apps?
  2. How often do you conduct competitive analysis, and are there any methods that you can share with us?
  3. What would be your suggestion for 3 Do’s and 3 Don’ts for Product Managers?

Check out the interview here!

How to Know You Know the Government’s Requirements for Your Product

How do you know that your product or service is compliant with government requirements? As a product manager, I’ve had to investigate legal requirements for my products. I’ve had to comply with ADA disability requirements, financial law, and transportation law. I highly recommend building a relationship with people who work for the government. Here are some tips for making sure you know the government’s requirements as the law – and your products – inevitably change.

  1. Attend industry events. This is how you can hear about current and future regulations that will impact your market.
  2. Make government connections. You can make these connections at industry events, but sometimes it’s much trickier. Sometimes you need an introduction from someone else.
  3. When you have a list of a few things you want to confirm, ask to have a meeting with them. I’m in favor of scheduling a phone call, and including people who won’t take over the call.
  4. For the meeting, make a list of things you believe are the requirements of the law. Go in prepared and let them correct you. instead of making them explain what could be dozens of pages of legal policy.
  5. Send a script to them of things you are going to ask. Let them come to the meeting prepared, too.
  6. Include what you think their answers are going to be in your script. I like to say, “my understanding of x is…” They’ll correct you when you’re wrong, possibly before the meeting.
  7. When communicating with your government connections, respect their time. Stick to your script. Avoid tangents. Don’t invite colleagues who will make the meeting longer than it needs to be.
  8. When communicating with your government connections, don’t tattle on your competitors or their clients. It’s tempting, but your focus is on your client and your product.
  9. When communicating with your government connections, don’t ask how to cheat the system. Again…tempting, but even a hypothetical cheating question will make you sound like you’re trying to cheat the system.
  10. Document what you discussed in your meeting for internal stakeholders. This is where that script comes in handy, because you’ll be able to use it to communicate with your stakeholders.
  11. Don’t give your government connections’ contact information to your clients. You should want your clients to trust you as the expert, and not bypass you to talk to your connection.
  12. When clients question your interpretation of the law, insist that you’re right. Be the expert that they need you to be.
  13. Treat the government like another one of your clients. They have requirements you have to fulfill, and sometimes you need to talk to them to clarify. It can be a very similar relationship. And you’ll want to treat them with the same respect.

 

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.

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!

12 Signs that the Product You’re Hearing about is Vaporware

No one wants to announce vaporware. It’s an act of desperation, probably stemming from poor long-range planning. It happens in all industries, and even occasionally in politics. When a company rep is telling you about a product that is coming in the next year, it’s a good idea to be skeptical. It may never come out, or the date may slide. The motive might be for you to wait for that product or feature, instead of moving to a competitor’s product like a lot of other folks. During an industry event, you might be surprised at how much vaporware is being announced. Here are some signs that a product is vaporware:

  1. The details of the product have changed. You first heard it was a product that integrated with Product B, and now it integrates with Product C. Or the name of the product has changed. Red flags!
  2. The scope of the product has decreased over time. The first time you heard about it, the product did A, B, and C. Now you’re hearing it does A, D, and E.
  3. Buzzwords. Cloud computing, virtualization, business intelligence, big data, data mining, de-dupe, and 4G/5G. There is no bigger buzzword in the software industry than “the Cloud.” Ask Paul Christman what he thinks about buzzwords.
  4. The company is losing customers left and right to existing products that compete with this product. The company is desperate to keep you from leaving them, too. If you were the company, wouldn’t you make promises to keep the customer?
  5. “We’ll change your industry with this product.” Don’t believe it until this announcement: “Today we change your industry with this product.”
  6. The way the company representative demoed the product to you was through a PowerPoint or PDF. No live demo? Why wasn’t it possible?
  7. There’s a surprising amount of leeway on price. Is this product being discounted significantly on a pre-order?
  8. They say that you can pre-order, yet none of the solutions they’re pitching to you today are available today. Hmm…are you an easy mark for this company?
  9. The company hasn’t produced a new product in a long time. The point here is not about company size…it’s about how companies that don’t release new products a lot forget how. Releasing a new product is HARD.
  10. There are press releases dating back more than a year. Is it normal for a company in your industry to announce things more than a year before they are released? For most industries, the answer is no.
  11. All the information you find on the product is word-for-word from press releases. Either the press releases are really, really good (like the ones from SalesForce) or the press in your industry is not being skeptical. Google is your friend to find this.
  12. The press/bloggers in your industry rarely call companies on their BS. Who is the watchdog who would tell you that this product is never going to be delivered? Are they really out there doing that or are they a puppet for the company, copying their press releases word-for-word?

Maybe YOU should be your industry’s watchdog! Go to industry events and make a note of products that you’re told are coming in the next year. A year later, publish/blog a list of the ones that have and haven’t arrived.

Don’t let the companies in your industry get away with being all hat and no cattle…