It was a very interesting and insightful read and you clearly presented in your article how realities differ from the concepts that we find in the books or talkshows etc.
While trying to read the shape-up method, back of my mind i was also thinking about if its possible to do something like this in my organisation and also was thinking about whether it would fit in to my organisation. Here are my two cents:
I am working in a B2B space in my org. where the contract period for customers are at around 2 years, so every-changing scenarios is not something that i would related my industry with, even though its a relatively new and growing market (charging and energy industry)but there are some set standards that needs to be followed or some set expectations from the market in terms of need and value. So for this specific industry, a little bit longer plan (around 1 year) is required to have an overview of what we are gonna build or want to achieve with our product, although nothing is concrete or set in stone so things can definitely change but the scope of change is not that big and frequent.
1. For us we have a 1 year roadmap for our product. Previously we had 6 months roadmap but we realize it wasn't enough to have a bigger picture of how we wanna shape our product. This input of roadmap of different product teams in our org is taking as a imp factor to define company wide OKRs which are yearly OKRs but that doesnt mean they can't be changed within the year. Through these company wide OKRs, team develop their own quarterly OKRs and work towards the common goal during the quarter.
2. In most cases, in our industry, you either know what the market demands in general and also you know from customer research, competitor analysis and feedback whether that the feature is important or not.
3. We now moving slowly towards more experimentation/ hypothesis driven approach to build features. So the product approach is also changing slowly at our org. :)
4. Well of course not all feature ends up being ready in 2 weeks like there are different tshirt sizes for features as S,M,L. I don't see it as a problem in our organisation and team. In the end you have done your prioritisation, your timeline check and the features are developed in a structured way that what we decide are completed during the quarter :)
5. So we create User Stories and we define what the end state of the feature or story should look like. So we as PMs define the outcome but on technical level what would be the best solution is usually defined by the Product Owners and Engineers :)
I hope this gave you some sort of understanding how things run at our organisation. I think what's important is we keep our eyes and mind open to changes, be agile about it, not just at the level of features but also teams or organisation as well :)
This was a great read. Your initial points about product management in theory vs reality is something I think about a lot. It still feels like we’re all just trying to figure out how do be a PM. Every book I read just gives more advice and different suggestions on how to do the job more effectively and it gets to be to much. I started to cringe reading about the shape-up method, not because I am not open to it, but because it’s one more way to do this job. I really do believe every team is different and everyone has their own way about product. To your point, many product practices. As long as there are consistent product values in place, it seems to be ok.
To your questions:
1. The roadmap is almost secondary to our quarterly OKRs. We are a young company and seem to thrive off those more so than the roadmap. This is a very different experience than I have had in the past.
2. The team understands everything on the roadmap is fluid and may or may not happen. We try to do a lot of experiments to gauge success.
3. The only items that get pushed hard are the ones that come from top down. I still struggle to tell a CEO their vision will not work, so instead we prove it can or cannot with metrics.
4. The 2 week sprint cycle does not work for my team. We should probably be leaning more into Kanban.
5. Sometimes I can be to descriptive in my requirements to the designers or tech lead. Unfortunately it comes from my team not having enough time to spend on things so I “help” by sometimes drawing things out. It’s not a good habit.
First of all enjoyed the new format and a very candid take on PM practices at orgs.
1. Most orgs are trying to have shorter roadmaps- 6 months mostly
2. No straight answers here. While team knows that success of any feature is not guaranteed but there no explicit conversations about features being a "bet".
This I feel is driven by the fact that as PMs we are expected to champions for what we are building and any doubt might negatively impact the morale of the team.
3. This is rather challenging but acknowledging feedback during User stories and Prototyping can be a starting point.
4. Nothing gets done in 2 weeks, minimum 6-8 weeks to deliver any meaningful feature
5. Detailed to the level of Mandatory params, rules and UI aspects are defined by PMs- This I feel is specific to the industry as most any feature has to comply with internal compliance and regulatory guidelines.
Hey Bandan,
It was a very interesting and insightful read and you clearly presented in your article how realities differ from the concepts that we find in the books or talkshows etc.
While trying to read the shape-up method, back of my mind i was also thinking about if its possible to do something like this in my organisation and also was thinking about whether it would fit in to my organisation. Here are my two cents:
I am working in a B2B space in my org. where the contract period for customers are at around 2 years, so every-changing scenarios is not something that i would related my industry with, even though its a relatively new and growing market (charging and energy industry)but there are some set standards that needs to be followed or some set expectations from the market in terms of need and value. So for this specific industry, a little bit longer plan (around 1 year) is required to have an overview of what we are gonna build or want to achieve with our product, although nothing is concrete or set in stone so things can definitely change but the scope of change is not that big and frequent.
1. For us we have a 1 year roadmap for our product. Previously we had 6 months roadmap but we realize it wasn't enough to have a bigger picture of how we wanna shape our product. This input of roadmap of different product teams in our org is taking as a imp factor to define company wide OKRs which are yearly OKRs but that doesnt mean they can't be changed within the year. Through these company wide OKRs, team develop their own quarterly OKRs and work towards the common goal during the quarter.
2. In most cases, in our industry, you either know what the market demands in general and also you know from customer research, competitor analysis and feedback whether that the feature is important or not.
3. We now moving slowly towards more experimentation/ hypothesis driven approach to build features. So the product approach is also changing slowly at our org. :)
4. Well of course not all feature ends up being ready in 2 weeks like there are different tshirt sizes for features as S,M,L. I don't see it as a problem in our organisation and team. In the end you have done your prioritisation, your timeline check and the features are developed in a structured way that what we decide are completed during the quarter :)
5. So we create User Stories and we define what the end state of the feature or story should look like. So we as PMs define the outcome but on technical level what would be the best solution is usually defined by the Product Owners and Engineers :)
I hope this gave you some sort of understanding how things run at our organisation. I think what's important is we keep our eyes and mind open to changes, be agile about it, not just at the level of features but also teams or organisation as well :)
This was a great read. Your initial points about product management in theory vs reality is something I think about a lot. It still feels like we’re all just trying to figure out how do be a PM. Every book I read just gives more advice and different suggestions on how to do the job more effectively and it gets to be to much. I started to cringe reading about the shape-up method, not because I am not open to it, but because it’s one more way to do this job. I really do believe every team is different and everyone has their own way about product. To your point, many product practices. As long as there are consistent product values in place, it seems to be ok.
To your questions:
1. The roadmap is almost secondary to our quarterly OKRs. We are a young company and seem to thrive off those more so than the roadmap. This is a very different experience than I have had in the past.
2. The team understands everything on the roadmap is fluid and may or may not happen. We try to do a lot of experiments to gauge success.
3. The only items that get pushed hard are the ones that come from top down. I still struggle to tell a CEO their vision will not work, so instead we prove it can or cannot with metrics.
4. The 2 week sprint cycle does not work for my team. We should probably be leaning more into Kanban.
5. Sometimes I can be to descriptive in my requirements to the designers or tech lead. Unfortunately it comes from my team not having enough time to spend on things so I “help” by sometimes drawing things out. It’s not a good habit.
First of all enjoyed the new format and a very candid take on PM practices at orgs.
1. Most orgs are trying to have shorter roadmaps- 6 months mostly
2. No straight answers here. While team knows that success of any feature is not guaranteed but there no explicit conversations about features being a "bet".
This I feel is driven by the fact that as PMs we are expected to champions for what we are building and any doubt might negatively impact the morale of the team.
3. This is rather challenging but acknowledging feedback during User stories and Prototyping can be a starting point.
4. Nothing gets done in 2 weeks, minimum 6-8 weeks to deliver any meaningful feature
5. Detailed to the level of Mandatory params, rules and UI aspects are defined by PMs- This I feel is specific to the industry as most any feature has to comply with internal compliance and regulatory guidelines.
ps- looking forward to GDs now