Archive for the ‘Business’ Category

A thought-provoking read which explains the impossibility of predicting a certain future, but using #experiments, working together and staying open-minded results in a more probable future.

Remarkably this book was written just before the Covid-19 pandemic!

Even though futures are impossible to predict, by having shared, passionate guiding #principles or an inspiring #vision can increase the chances of reaching our goals even with extreme uncertainty, where we only need to look at how art and cathedrals are created as evidence of this.

The book touches on how traditional management is addicted to masterplans and want safety and certainty, not creativity and risk that come with experimentation, which as a result constrains their chance to map a safer future. This section reminded me of Waterfall vs. #Lean/#Agile.

More automation is a common prediction of the future, but Margaret explains that this comes with a risk of falling into a trap: more need for certainty, more dependency on technology; less skill, more need. The more we depend on machines to think for us the less good we become of thinking for ourselves.

“Making the future is a collective activity…the capacity to see multiple futures depends critically on the widest possible range of contributors and collaborators.”

Seeing content by Gary Vaynerchuk for a while now driven by passion and authenticity, I thought his book would be a good read and I wasn’t disappointed.

Like a lot of his content, he gives an authentic and passionate insight into what it takes to achieve your full potential and goals in life.

The book is loaded with questions he’s been asked over the years where he responds with concised authentic answers, with enough context to make you feel inspired and motivated.

“Pumping everyone full of confidence makes for a more creative, risk-taking environment.”

“Passion is an unmatched fuel”

“Maybe we all look for excuses to explain why we don’t achieve what we want to, and we should be more self-aware and recognize how much control we actually have over our own fate…it’s amazing how as soon as you make the shift from “I can’t” to “Why can’t I?” you go from defense to offense, and as everyone knows, the best place to score is always on offense.”

“The only effective way to truly lead is to practice and model the behaviour you want to see in others…the top has to ensure that its values, beliefs, and attitudes trickle down to shape the culture and encourage a productive, innovative, creative, and even happy environment.”

Bubble: Bitcoin (Crypto) becoming a mainstream payment method and that Crypto is decentralised.

Revolution: Private blockchains used to improve supply chain efficiency for businesses and Crypto being a viable investment, as well as used as a payment method for large/international transactions.

Walmart used IBM’s Food Trust private blockchain to improve the efficiency of their supply chain making over a hundred thousand-fold speed improvement from farm to Walmart. Microsoft with the Xbox also made significant efficiency gains by implementing the same private blockchain strategy to improve the royalty settlement and new publisher flows.

Microsoft Azure, Amazon Web Services, Oracle, Google Cloud and IBM already offer private blockchain solutions.

Zynga, Etsy, Microsoft, Burger King, KFC, Virgin, Expedia and many others already accept Bitcoin payments.

The stock exchange industry could save $20 billion from blockchain-based clearing.

There is 1 in 66 billion trillion chance of someone mining a block (which is used to validate transactions and receive a Bitcoin reward for their effort).

Whilst only 21 million Bitcoins will ever be available (3 million left to mine), each Bitcoin is equal to 100 million Satoshis, with a Satoshi being the minimum amount you can exchange, making it an investment for everyone.

To verify a single Bitcoin transaction uses enough electricity to power an average household for 22 days and generates the same carbon footprint as over 750,000 Visa transactions.

In order to mine, you need a mining farm (a set of super computers) which are primarily owned by a small group of people that are employed and funded by a single company. Also China owns 80% of the market for Bitcoin mining hardware which is being integrated with the monetary system, adopted by banks, and regulated by governments…so not so decentralised.

Bitcoin can only process about 3 transactions per second, Ethereum 15 per second and Visa 45,000 per second.

To send $10 from US to Indonesia it’s impossible via bank transfer, costs $30 via UPS and only costs $1 via Bitcoin. To send $10k the fee is $400 via bank transfer, $150 via UPS and still only $1 via Bitcoin. In fact, it would still be just $1 fee via Bitcoin if you was to send $10m whereas the fee via bank transfer would be $400k.

Crypto exchanges already support KYC and AML regulations, making it  ready for iGaming and other highly regulated industries.

“The two biggest use cases for crypto going forwards will be payment methods (primarily for large or international transfers) and investments (supplementing, but not replacing, stocks and bonds).”

In this book, Neel Mehta, 🚀 Adi Agashe and 📍 Parth Detroja break down this highly complex set of tech into a digestible, balanced and comprehensive guide, which I’d recommend to anyone who doesn’t know about the benefits, challenges and future of blockchain and cryptocurrencies.

Lastly it was nice to hear that the creator (Satoshi) of this innovative tech is a fellow Brit.

Martin Luther King inspired millions to stand up against inequality and injustice, because he started with WHY.

Apple is worth $2 trillion and managed to build a cultish loyal following, because Steve Jobs always started with WHY.

Simon Sinek is able to repeat his success again and again and inspire others to do the same, because he focuses on WHY.

The Wright Brothers managed to invent, build and fly the first motor operated airplane, because they started with WHY.

Becoming a billion-dollar business or change the course of industries requires a rare special partnership between one who knows WHY and those who know HOW.

Employees give 110% to the mission, when they know WHY.

People don’t buy WHAT you do, they buy WHY you do it.

Another inspiring book by Simon which I’d recommend to anyone in a leadership role.

Very inspiring book by Simon Sinek, where he explains a concept called Circle of Safety, where only when people feel safe will they pull together as a unified team, better able to survive and thrive regardless of the conditions outside.

“When we feel sure they will keep us safe, we will march behind them and work tirelessly to see their visions come to life and proudly call ourselves their followers.”

The book explains well that a title doesn’t make you a leader, but instead leading with purpose having empathy, trust, integrity and creating a safe autonomous environment is key to being an effective leader.

Simon includes stories of the damage which unhealthy cultures can have, includes detailed explanations of the science behind why some teams pull together and some don’t and has fascinating insights into how leadership has changed over the generations which includes an extra chapter on how to lead Millennials.

It’s a must read for anyone responsible for defining and delivering a vision.

In this book L. David Marquet tells a remarkable true story of how he transformed a low performing team of 134 passive followers, into high performing empowered active leaders who received a plethora of awards as a result of their successes.

Marquet explains “You may be able to “buy” a person’s back with a paycheck, position, power, or fear, but human being’s genius, passion, loyalty, and tenancious creativity are volunteered only.”

Having independent, energetic, emotionally committed and engaged individuals thinking about what they needed to do and ways to do it right achieved excellence.

“Simply providing data to the teams on their relative performance results in natural desire to improve.”

Guiding principles the team used to achieve excellence:

🔸️ Initiative
🔸️ Innovation
🔸️ Intimate Technical Knowledge
🔸️ Courage
🔸️ Commitment
🔸️ Continuous Improvement
🔸️ Integrity
🔸️ Empowerment
🔸️ Teamwork
🔸️ Openness
🔸️ Timeliness

Leadership at Every Level!

“Ultimately, the most important person to have control over is yourself – for it is that self-control that will allow you to “give control, create leaders”.”

This colossal 786 page desk reference provides a fantastic perspective for professionalising Product Management, inspired by Steven Haines vision for this profession.

Throughout the book it focused on a Cross-Functional Product Team, which most people would immediately think would be just a PO/PM and dev team, but instead it was refreshing to see product in the centre of the whole organisation and that product team including someone from marketing/sales, customer service, operations, development, legal…..also in my experience when a product manager brings this team together is where the magic happens.

Steven explains regardless of development methodology, it’s important to remember that the product manager is in charge of the product’s business, not just the product’s functionality, design or features.

“No one will bestow Product Management leadership on you. It is yours to own, to internalize, and to practice”

“Product Managers will earn greater levels of credibility across the organization when they understand and act on proven facts and relevant data”

This book will remain on my desk and I’d recommend it to any ambitious product manager.

The First 90 Days

Posted: Jan 1, 2021 in Book Reviews, Business
Tags:

Transitioning to a new role can cause anxiety and stress for weeks, but this book by Michael Watkins helps diagnose your situations, define the core challenges, and design plans to create momentum which results in a more successful and comfortable transition.

Hundreds of thousands of leaders have benefited from this approach, which independent research has shown reduces time to break-even by as much as 40%.

The book includes case studies of failed transitions and clearly explains how to avoid them by preparing yourself, setting your boundaries, listening, learning, collaborating, creating alliances, securing early wins and managing yourself.

“Effective leaders strike the right balance between doing (making things happen) and being (observing and reflecting)”…

…this nugget from the book is equally true even when you’re not transitioning to a new role.

I’d definitely recommend this book.

Fantastic book by Stephen R. Covey

If you’re into self-improvement I couldn’t recommend this highly enough.

Four generations of time management:

1st generation – notes and checklists

2nd generation – calendars and appointment books

3rd generation – important idea of prioritisation, of clarifying values, and of comparing the relative worth of activities based on their relationship to those values

4th generation – recognises that “time management” is really a misnomer-the challenge is not to manage time, but to manage ourselves

5th generation – tbc

Whilst I have minimal B2B product experience, this book by Geoffrey Moore gave good insight into the complexities and challenges of scaling high-tech products, as well as practical advice on how to avoid the various pitfalls when attempting.

Although the Crossing the Chasm model is B2B, I couldn’t help notice how many similarities there were to B2C when it comes to scaling a product to mainstream customers with a ‘whole product’ offering and targeting customer segments.

Agile

Whilst Agile frameworks such as Scrum and Kanban are a great way of taking steps towards becoming more Agile, it’s important to remember amongst their own principles and guidelines, that the ultimate objective is to deliver customer value/the product vision in an efficient and competitive way.

To help avoid losing sight of this objective and falling into the trap of obsessing about the intricate details of the frameworks too much, it’s important that gap analysis is done frequently on the actual Agile manifesto and principles themselves to see how you can shape the Agile framework to achieve agility and the real benefits of being Agile.
The 4 Agile Values/Manifesto

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

The 12 Agile Principles

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

How Spotify have adopted Agile

Strategy

VMOST = Vision, Missions, Objectives, Strategies and Tactics

Each product should have a clearly defined product vision, KPIs and strategies if it’s expected for the development team to deliver outcomes/head in the right direction, and using the VMOST canvas is an effective way of showcasing what these are in a clear and concise format.

VMOST example

Vision: A passionate and exciting statement which typically should only be one sentence, where in a nutshell it should explain what your ambition is/what is your end goal of the product and who it’s for. More info on creating a compelling product vision can be found here.

Missions: In order to achieve the product vision, there would be multiple high-level missions you need to go on – what are the biggest problems which need solving before achieving the vision.

Objectives (KPIs): You can track progress of your missions through setting multiple objectives (aka KPIs), which would include metrics which are measurable.

Strategies: Initiatives which would deliver/impact the objectives (KPIs).

Tactics: Multiple ideas (Epics) which would deliver each strategy. The tactics should be laid out on the product roadmap, so there’s a nice link between the product VMOST and product roadmap.

Although the product manager is responsible for defining and owning the product VMOST, it’s important that it doesn’t happen in silo, as it takes collaboration with the rest of the business especially stakeholders/data/customers/tech to help provide some guidance on the selection of problems to solve which would be represented on the VMOST.

Once the VMOST is ready, it’s time for the product manager to showcase this in a passionate way across the business and perhaps print it out on A0 to sit near the dev team on the wall, so it can always be top of mind.

Good luck in creating your VMOST!!

If a product is to be sustainable, tech fit, compliant and competitive it needs to have a short and long term development capacity strategy which will help to ultimately deliver the product vision.

Not having enough capacity could mean spending months / years only focusing on upgrading software versions / maintaining legacy technology or meeting regulatory requirements – not making any significant progress on getting after the product vision or surpassing competitors, having too much resource could mean that another product in the business could deliver a higher return with that resource instead, but having the right amout of capacity is important.

The product having the right amount of capacity should mean it’s possible to get after low hanging fruit, maintaining current tech whilst also concurrently getting after the next generation technology (product vision), meeting security / compliance requirements and having resource to experiment.

Understanding what the right amount of capacity should be isn’t easy, but a capacity planner will be able to help. A capacity planner should ideally be driven by points and velocity, so that no matter where the feature is on the feature pipeline (received a high level t-shirt size or has been broken down into stories) it’s possible to easily update the capacity planner with a more accurate estimate as the feature goes into development.

The data you’d typically need to lay out in a spreadsheet in order to effectively capacity plan includes:

  • Date (by month)
  • Team velocity – ‘Points to Allocate to Features’ (which already takes into account average sickness, holidays, ceremonies, breaks, training etc)
  • Forecast of future velocity based on an increase / decrease in capacity eg. Are you planning on adding another team to the product in 4 months time?
  • List of features
  • Estimates (in story points) against each feature
  • Priority order of features
  • ‘Points Remaining’ which is calculated as you start filling up the spreadsheet

It’s totally possible to roughly estimate future features by dev sprints, team sprints or man days instead of points as long as you convert it back to points after knowing how many points a whole team burns each sprint (velocity).

Another reason why it’s essential to have a capacity planner is that based on when features start and finish on the plan will drive the product roadmap dates making the roadmap data driven.

Having a capacity planner available is also a handy report when demonstrating to stakeholders that when features are in the correct priority order and once capacity has run out for a given month, then there’s no more room to slip in anymore work and it’s a case of being patient or changing priority / increasing capacity.

Basics

As a product scales there would often be an increase in capacity / scrum teams working on that product, enabling multiple features to be worked on concurrently, which would be a sensible time to review whether it’s time to adopt the LeSS (Large Scaled Scrum) framework.

As there are some additional elements involved in LeSS vs. Scrum including:

  • All of the Scrum teams work as one team, from one product backlog and with one Product Manager to deliver common goals
  • Having a joint sprint planning with members of each scrum team to decide on what product backlog items (PBIs) to commit to delivering in the next sprint
  • Overall Backlog Grooming (OBG) where members of each scrum team decide on what PBIs to assign to what teams, so they know what features to groom and get in a ready state for an upcoming sprint
  • Overall Retrospective where members of each team discuss highlights from their individual team retrospectives with the aim to learn and improve on how the whole team operates

It’s important to ensure that the Scrum teams have mastered the key elements of Scrum before considering using the LeSS framework, so before moving over to LeSS, see how you’re doing against the below questions:

  1. Are the teams using velocity to measure whether process changes they make are improving their productivity or hurting it?
  2. Are fast estimation sessions happening frequently so that the product backlog has rough estimates?
  3. Is it easy to predict when software will be delivered for the current and future projects based on the backlog being sized?
  4. Are sprint burndown charts monitored every day?
  5. Is analytics part of the definition of done?
  6. Is there a strong DevOps culture in all of the teams?

If the answer is ‘no’ to any of these then perhaps it’s a bit too early to adopt LeSS.

Idea

Getting an idea (problem) to customers (solution) is a complex cycle no matter what organisation you work in, but constantly monitoring and optimising the whole cycle will make it as smooth and efficient as possible improving the ROI for product iterations.

Irrelevant of the size of the problem that you’re looking to solve, it’s still important to firstly understand the value of the problem – why does it need to be discussed any further let alone hit the development teams for rough sizing? Unless you have data or a solid rationale to specify the size of the problem or opportunity, it simply shouldn’t go any further than the analysis stage. Not only is the value crucial for prioritisation, but it’s also important for the development team to know the benefit of working on the PBI (Product Backlog Item).

Once you’re confident the problem is worth solving, then it’s time to set the priority by weighing up the opportunity with all other PBIs and having a gut feel on size is totally acceptable at this stage to avoid draining the development team time with every single idea and talking about work, rather than progressing with solving high priority problems.

Before the feature touches a team for grooming it’s important for Product, Delivery and Technical to collaborate on how much resource gets assigned to solving the problem or phase eg. One team, two teams or all teams – depending on the option could impact in flight features and efficiency, so it’s important to collaborate over different delivery scenarios before rushing into a decision just because a deadline looms, as getting more teams onto a problem to solve could make the delivery go slower and impact efficiency unnecessarily.

Getting a PBI / Feature from idea to a ‘ready‘ state for development stage takes a significant amount of grooming which involves the Product Manager, Development Team and Technical Architect all of which is vital to ensure that when development starts that the right problem is going to get solved in the right way, rather than anyone wondering during development what problem they’re solving, what the value is or having to do loads of rework further down the line. This is one of most important parts of the delivery phases with the key elements being:

  • Solid ‘As a’, ‘I want’, ‘So that’ description which should give a crystal clear indication of who wants what and why
  • ‘Value’ of the problem
  • Acceptance Criteria of the requirement
  • Background / context which could be a link to Confluence which shows ‘As Is’ and ‘To Be’ flows / UX and can be used as part of a kick of for the feature to the development team
  • Any dependencies
  • Notes from the team working with the Technical Architect on any up front technical designs

When the PBI is in a ‘Ready’ state and prioritised high enough, then it goes into development whether that’s in a Sprint if it’s Scrum or on a Kanban board. The ‘in development’ phase gives you the most opportunity to improve efficiency / throughput and the Scrum Master is key to help the team achieve this (continuous improvements) whether it’s helping unblock impediments, coordinate with other development product lines or suggesting ways of getting PBIs over the line. There’s no harm also in hiring a Scrum Master for a team using Kanban, as ultimately the Scrum Master role is to help / support the team progress and the things which a Scrum Master would help out a team for Scrum would also apply to Kanban eg. Chasing down impediments, coordinating dependencies, removing blockers and working with the Product Manager on improving the quality of the Product Backlog.

Delivery

Once the ‘Definition of Done‘ (DoD) has been met including demo approved, it’s time to ship the product iteration to customers. Believe it or not, after all the work that happens prior to this, the release process is the part that could get stuck for weeks depending on the architecture and how the release process is monitored for Scrum (as often it’s outside of the DoD), but again this is where the Scrum Master can really step in to add value coordinating with release managers, but also suggesting release, environment and pipeline improvements to the development team and PO by reviewing delivery KPIs. For Kanban, tracking the release process is much easier as every process up to live gets incorporated on the Kanban board as there’s no set time boundary aka sprint.

Lastly it’s time to go back to step 1 (the analysis phase) and iterating based on how customers use the latest product iteration.

Like I said at the start, the Idea to Customer cycle is complex and involves a lot of people, but monitoring, testing out other agile frameworks and optimising the phases within the whole cycle will yield in a higher & quality throughput of features getting delivered to customers, so it’s important that the people responsible for Product, Delivery and Technical collaborate closely having this high up on their agenda and regularly communicate to the business the fantastic efficiency improvements which have happened recently and what’s up next to optimise.

CSPO

Whether you’re a product led organisation or keen to take product ownership to the next level, a good way to ensure that Product Owners are well equiped to effectively handle their product in an agile environment is through various Product Owner Certifications.

The first level of certification is becoming a Certified Scrum Product Owner, where the course is typically over a two day period with modules including:

  • Introductions to Agile and Scrum
  • Agile Basics
  • Scrum Basics
  • Roles and responsibilities
  • Team Chartering (Ready, ‘Done’ and Team agreements)
  • Product Visions
  • Product Roadmaps
  • User Stories
  • The Product Backlog and Product Backlog Refinement
  • Agile Estimating and Planning
  • Sprints
  • Participant-Driven Q&A

Acspo

Once you’ve become a Certified Scrum Product Owner and you want to take product ownership to the next level then attend the Advanced Certified Scrum Product Owner® course which includes:

  • Product Backlog Prioritisation & Refinement
  • User Stories
  • Rapid Vision Generation
  • Roadmapping That Works
  • Value Proposition Design
  • Hypothesis Testing
  • Use Cases
  • Getting to Done
  • In-person Collaboration
  • On-line Collaboration with Weave
  • Understanding Yourself as a Product Owner
  • Lift-off for Agile Teams
  • Scaling Scrum and other Agile processes
  • Extreme Programming
  • Facilitative Listening I & II
  • Inclusive Solutions

Csppo

The final step is becoming a Certified Scrum Professional Product Owner. Certified Scrum Professionals challenge their teams to improve the way Scrum and other Agile techniques are applied. They have demonstrated experience, documented training, and proven knowledge in the art of Scrum.

Are you ready for the next level of experience and expertise in the art of Scrum? If so, it’s time to elevate your career further by earning the CSP®credential.

Ownership

The product development lifecycle is complex, but in order for it to run like a well oiled machine there needs to be solid product management at the heart.

The below video explains Agile Product Ownership incredibly well and covers:

A typical Product Manager R&R would also be:

  • Market analysis
  • Competitor analysis
  • Customer analysis
  • Trends
  • Product line strategy
  • Product Vision
  • Product Roadmap
  • Backlog prioritisation
  • Epic / feature scoping
  • Epic breakdown to user stories
  • Requirement workshops and documenting them
  • User story definition
  • Detailed acceptance criteria
  • Backlog grooming
  • Sprint planning
  • Acceptance of user stories
  • Retrospectives
  • Daily stand-up

More info here on how to scale product when the time is right.

Learning

There are three major types of learning:

  1. Learning through association – Classical Conditioning
  2. Learning through consequences – Operant Conditioning
  3. Learning through observation – Modeling/Observational Learning

This article is focusing around No2 (learning through consequences) and the reason for focusing on this is because it’s so popular for fellow work colleagues across any business to recognise a problem / something not getting done and the consequences of not solving / doing it, that they just get stuck in and solve it themselves because they’re passionate about the business they work for instead of leaving it for the person whose responsibility it is to solve the problem / complete the task with risk that it’ll likely not get done.

Now, many people would say that’s brilliant team work and a fantastic ‘One Team’ attitude, but actually the action of solving someone else’s problem / completing a task for them is stopping the actual person whose responsibility it is to do it from learning. Also there’s the point about the person should be doing what they’re paid to do, but most importantly unless people experience the consequences of not doing elements of their job, then they’re simply not going to learn the importance of doing that element of the job and that they need to perhaps adjust their processes or admin to ensure they take control of their responsibilities in future.

Like I said at the start, if you’re passionate about delivering value for the business then it’s certainly not easy to avoid getting stuck in and it’s hard to avoid reminding people to do their job, but if you want to achieve the goal of the person who should be solving the problem or doing the task actually does it as expected in future, then the only way this will happen in the long run is by that person recognising the consequences of it not being done, so then they can avoid leaving it in future.

There will naturally be times when someone is clearly over worked and can do with a hand and that’s where you could come in to help, but if it’s someone close by spending most of their time surfing the net or playing ping pong in the games room, then you need to take a step back, try and ignore the problem not getting solved allowing them to deal with it however they feel is effective, but what is for certain is that problems / processes don’t normally get done on their own.

Once a product is mature and the product roadmap is filled up with valuable product iterations, it’s likely that the CPO will be keen to find out how some of the most valuable customer problems can be delivered sooner.

Having to balance customer problems, marketing, technology improvements, technical debt, regulatory, security, bugs and dev ops requirements with only one development team would make this extremely difficult, as there’s little room to work on all of these different types of work concurrently eg. customer problems concurrently with the more technical driven requirements.

To work on different sets of requirements concurrently, the product would need to scale which would involve adding additional product development teams to the product line. With more development teams working on the product would also require additional firepower from the technical architect and product manager role if delivery is to remain efficient and ROI positive.

An example of how you can scale the product manager role across multiple development teams who are working on the same product line:

Chief Product Officer (CPO)

  • Responsible for ensuring that the Product Managers are handling their product lines effectively
  • Handling the high level product strategy across all product lines

Senior Product Manager / Lead Product Manager of the Product Line

  • Market analysis
  • Competitor analysis
  • Customer analysis
  • Trends
  • Product line strategy
  • Product Vision
  • Product Roadmap
  • Backlog prioritisation
  • Epic / feature scoping
  • Backlog grooming
  • Sprint planning

Product Manager / Associate Product Manager working with the Development Team

  • Contributing to the product vision and roadmap
  • Customer analysis
  • Epic breakdown
  • Requirement workshops
  • User story definition
  • Detailed acceptance criteria
  • Backlog grooming
  • Sprint planning
  • Acceptance of user stories
  • Retrospectives
  • Daily stand-up

The Associate Product Manager could also be referred to as Feature Product Manager, Junior Product Manager, Product Executive or Business Analyst.

In order for the Senior/Lead Product Manager to be able to focus on the product vision, prioritisation of the product backlog and product strategy to ensure the product remains competitive, it’s important that when adding additional development teams to the product that they get additional product manager support to help them out with the more tactical day to day activities, as you can see from the split in tasks above – Product Line Managers handling more strategic tasks especially prioritisation in all instances and the Associate Product Manager handles more tactical tasks.

Spreading a product manager too thin with little support could result in a lack of focus on both product strategy and getting product backlog items delivered in an efficient way.

Greener

There will always be an endless list of all kinds of problems for a business to solve and it’s how people come together to solve the problems which accelerates the execution of viable solutions and positive changes.

Some problems will be easier to solve than others, there will be a multitude of lengthy conversations about how to solve certain problems and there will be various opinions on the value of the problem to solve, but it’s important to respect the person responsible (and accountable) for solving the particular problem and rather than moan about things not being solved / done how you’d expect, then use influence, positivity and collaboration instead to see how things could look from a different perspective, because ultimately everyone’s heading for the same goal and would be passionate to solve problems in the most effective way.

It’s also not easy to ignore a process which you seem to have various problems with especially when it’s not a priority to solve for the person who’s responsibility it is making you feel frustrated, but you could try rewiring your brain to obsess about problems which are within your remit to solve or contribute to solving instead and when asked by senior management “what improvements do you think we can make outside of your remit?” then you’re totally within your right to give an honest answer along with what you’ve tried to do to help.

Before you jump ship because you think the grass is greener, have you thought about:

  1. Collaborating on the solution with the person directly whose responsibility it is to solve the problem in a positive way – you never know, the person who’s responsibility it is to handle the process with the particular problem at hand could do with your observations or opinion on how to overcome the problems they’re facing
  2. Obsessing about solving problems which you’re responsible for and reviewing whether you’re fulfilling all of your R&R, as not solving your own problems could have a direct impact on other areas trying to solve their own problems
  3. Discussing openly with your line manager about how they think you could help contribute to solving the problem
  4. Is it a valuable problem to solve relative to other problems across the business
  5. Listing out all of the positive and good things about the company
  6. How lucky you actually are
  7. Making more conversations
  8. How much autonomy you already have to make big changes

When you get approached with an attractive offer by a recruiter or are fed up of certain problems not being solved, have a real think about how you’ve made an effort to help solve the problem by collaborating, because you may find the same problems if not more might exist on the other side of the fence, resulting in being in the same position in six months time with your new company.