What planning should be done for modifications to the entire product?

Resources for product managers Tools and pro-tips
, ,
1

What kind of organized strategy would you use to plan for product-wide changes?
Say, for instance, that Prowess has chosen to use actual names and images of real individuals for all avatars.

Of course, there are a number of things that must occur; how does the group PM specify this and pass it on to the PMs? How much is mandated, and how much is allowed to the product teams’ joint decision-making?

How can we specifically determine all the places that the change may affect and whether it will break any current features or functionality?

10 Likes
2

I’m not sure if there is a definitive response to your queries.

  • Multiple teams, not just the product org, would need to be involved in figuring out the magnitude and implications of these modifications.

  • Infrastructure, storage, and oversight for profile photos

  • Implications for privacy of storing actual names

  • Current dependencies with username for the backend

  • Retrograde compatibility (e.g., usernames mention on comments)

  • Implications of identical real names

  • The list is essentially endless.

If I had to handle this project alone, I would put together a multidisciplinary pod.

10 Likes
3

Yep. It is similar to other things. Invest time in defining the issue up front. Hold team meetings until all the uncertainties are clarified and you have a generalized list of tasks and milestones with estimated completion times. After that, you have a plan that you can follow and comprehend. You might also have some acceptance criteria for the epicm and artefacts like a gantt chart.

9 Likes
4

I believe I’m more interested in the fact that one of the processes would be determining how all new modifications will impact existing capabilities. Like you said, it’s simple to guess that user name mentions will be affected off the top of your head, but what about another random, more obscure feature if it’s a major product?

Is there a scientific approach here? to do a review of each area that could be impacted by a change?

Automated regression testing in engineering may reveal broken changes, but what would the product equivalent be? I think it would be too late to wait for eng.

8 Likes
5

Planning for product-wide changes can be a complex task, but there are some steps that can be followed to make the process smoother and more effective:

  1. Define the objectives and scope of the changes: Start by clearly defining the goals you want to achieve with the product-wide changes. This will help you determine the scope of the changes and set priorities.
  2. Assess the impact: Determine the potential impact of the changes on your customers, team, and business. This will help you identify potential risks, dependencies, and trade-offs.
  3. Develop a plan: Create a detailed plan that outlines the steps you need to take to implement the changes. This plan should include timelines, milestones, and deliverables.
  4. Communicate the plan: Communicate the plan to your team, stakeholders, and customers. This will help ensure that everyone is aware of the changes and understands what is expected of them.
  5. Test and iterate: Test the changes in a controlled environment and gather feedback from customers and team members. Use this feedback to refine and iterate on the changes before rolling them out more widely.
  6. Monitor and measure: Monitor the impact of the changes on your customers, team, and business. Use data to measure the success of the changes and make adjustments as needed.
  7. Rollout the changes: Once you have tested and refined the changes, roll them out to your customers and team. Ensure that everyone is trained and supported throughout the process.

By following these steps, you can plan and implement product-wide changes in a way that minimizes disruption, maximizes impact, and ensures the best possible outcomes for your customers and business.

7 Likes
6

To identify all the areas that might be affected by a product-wide change, and whether it would break certain existing features/functionality, you could use the following approaches:

  1. Conduct a thorough impact assessment: This involves analyzing the potential impact of the change on all areas of the product. The impact assessment should consider how the change affects the user experience, technical architecture, data structures, integrations, and other relevant factors.
  2. Review existing documentation: Reviewing existing documentation such as product requirements, design specifications, and technical documentation can help identify potential areas of impact. This can include identifying dependencies on existing features, integrations with third-party services, and potential compatibility issues.
  3. Conduct user testing and feedback: User testing and feedback can help identify potential issues with the change from a user perspective. This can include identifying areas where the change may negatively impact the user experience, or where existing features may no longer work as intended.
  4. Involve relevant stakeholders: Involving relevant stakeholders such as product managers, designers, developers, and quality assurance teams can help identify potential areas of impact and ensure that the change aligns with the overall product strategy.
  5. Conduct a technical review: Conducting a technical review can help identify potential issues with the change from a technical perspective. This can include identifying potential performance bottlenecks, security risks, or compatibility issues.
  6. Conduct a phased rollout: A phased rollout can help identify potential issues with the change in a controlled environment before rolling it out more widely. This can include testing the change with a subset of users or in a test environment before deploying it to all users.

By using these approaches, you can identify potential areas of impact and ensure that the change is thoroughly tested before deploying it to all users. This can help minimize the risk of breaking existing features or functionality, and ensure a smooth transition to the new product-wide change.

6 Likes
7

Not to oversimplify but you have to scale your discovery, planning, staffing, testing, and change management to correspond to the size and impact of the change. Start with an overall process similar to an enterprise technology transformation, but with an agile, product approach.

5 Likes
8

Opportunity mapping.

Map out your options and run your lean tests.

A little multivariate testing until you find what works.

Then plan out your transition.

4 Likes
9

I get what you’re getting at, is there a method more defined than just “ask everybody attached to the system at hand” and I think the answer is likely no. I have yet to see a company wide system architecture pointing out all implications of an action, so I think your best bet is brainstorming with a team across the organization of how it could go wrong (a pre-mortem) and digging in further.

3 Likes
10

This depends on the size of your org. For a large company like Reddit, I imagine the process will look something like this:

  • consult with the lead engineer or engineering manger.
  • get some high level technical research done on what systems will be impacted and what exisiting legacy constraints you have
  • figure out what departments will need to be consulted before the change rolls out, i.e. legal, marketing or data/analytics.
  • figure out what dependencies on other eng or product teams you’ll have with this new change and then de-risk the delivery timeline.
  • get sign off from big dogs (aka wider stakeholders / execs)
  • start implementation and rinse and repeat. I imagine the above steps will need to be done repeatedly as you uncover new things

Feel like the trick with project management is to always identify risks and triage the impact and diligently go after the big ones

2 Likes
11

This is kind of bad advice but for more local-scale stuff sometimes you can try to change it and there will be a blocker in place for things that affect a wide amount of people

1 Like
12

Here is how I would probably go about doing it -

  1. Understand why we are doing so. This should bring us clarity in terms of what is the core outcome being driven and would help prioritize changes across the board. Such a change may not just be on engg side but also on product proposition(anonymity gone), marketing, design, revenue oppurtunity etc. So knowing what is the main goal of doing such change would help make decisions across various teams in a decentralized manner.
  2. Ask engineering - they know the code so ask for an impact analysis from a tech side - what all modules may be impacted etc. For each of those impacts, try and draw out impacts on users and other stakeholders. Try n think a couple of steps ahead - if I change this, then immediately xyz would happen, and later on, this may happen too, so I need to be prepared for it.
  3. Do a harmless pilot as part of discovery - in the problem that you have mentioned, make the change on one account and try to assess the impact. It may reveal certain other areas not caught by product or engg.
  4. Communication - Internal as well as External - why we are doing, how it would impact anyone, what is the benefit, can one opt out of it etc.
  5. Testing, testing and more testing - making sure existing stuff isn’t broken at the very least.
  6. Staggered launch - enable it in parts. Maybe demographic wise, so if there is a blow back, it is containable.