Archive for the ‘Business’ Category

In a startup, it’s common for the c-suite to function as the product manager until product-market fit has been validated.

Once validated, it’s time to build the product for real which would require a product manager to work in a product team that also includes a product designer and several engineers to continue learning and solving customer problems/demands.

As the product grows, so does the business and resources, then before you know it, the product manager is running around trying to keep the product afloat by keeping customers happy, growing the product, validating ideas, managing expectations with stakeholders and ensuring that the product is on the right strategic track. The full breadth of the product manager role is vast!

At the same time of growing resources across the business, it’s essential to consider scaling the product management team, but before this happens you need to define your product lines/areas/verticals, so then you can hire product managers to manage, own and be accountable for a particular product line/area/vertical.

The best way to split up your product into lines is across the core value streams/customer experiences, for example:

  • Cashier – Payment/withdrawal flows
  • Compliance – Login flows/security, regulatory flows, marketing preferences/data protection flows
  • Growth – Acquisition/CRM flows, account, and any MarTech integrations needed to achieve the growth OKRs
  • Engagement – Focusing on driving engagements
  • Community – Initiatives to drive social engagements
  • Gaming Integrations, content management and gaming experience
  • Sportsbook – Integrations, trading and betting experience
  • Web – Providing customers with the optimal web experience
  • Apps – Providing customers with the optimal app experience through the App/Play Store

The Product Manager is fully accountable for the success of their product line, so as well as defining the product vision, KPIs, strategies and product roadmap for their product line, they would also be part of an Agile product team (including a product designer and engineers) who would together manage the product backlog, execute the VMOST, product backlog items (PBIs) and test hypothesis.

Now, letting product teams manage a specific product line (which comes with ownership (autonomy and empowerment)) can be a terrifying thought for some businesses since they often prefer a more controlled project management approach, which is why they just hire product managers (or product owners) and stick them in a scrum team to execute projects from a pre-defined roadmap. Marty Cagan articulates this widespread problem and its impacts well in his recent article on project teams vs. product teams.

Saying this, there are also some challenges when transforming to a product line structure:

BenefitsChallenges
Clear product ownership across the businessManaging cross product line/area dependencies although tools such as Aha! certainly helps
Accountability for KPIs and live product supportMore effort needed on alignment especially on high priority cross-cutting initiatives
AutonomySwitching to a more learning, trust and empowered culture which isn’t always quick and easy
Empowered product teams
Focus on outcomes over outputs
Domain expert knowledge
Efficiency
Ability to continually improve key product areas staying ahead of the competition
Leaders at every level
Product/tech team retention

Essentially, what product lines give you if done effectively, is empowered mission-focused Agile product teams who are motivated to execute the VMOST which they defined for their product area in collaboration with key stakeholders.

The outcome of this is having a best-of-breed product, delivering more customer value quicker.

There’s a lot of confusion around product management job titles, seniority, and hierarchy. This has become more prominent since organisations started creating the Product Owner job during their Agile transformation using the Scrum framework, even though Product Owner is a role that a Product Manager plays rather than a job in itself. This makes it hard to compare jobs, plan your career, and attract the right talent to your team.

Inspired by Mind the Product, in this article I’ll walk through the product manager levels, providing overviews for each product role, and some useful content to refer to.

Associate Product Manager (APM)

This is an entry-level product position, for someone who is brand new to the role.

An APM can be a recent graduate who would enter into a rotational apprenticeship program across the business. The aim—similar to most apprenticeships—is to develop these candidates into full-time positions through a combination of training and hands-on involvement with real projects.

Alternatively and the most common route, an APM has some work experience under their belt already and can come from any background. Engineering, marketing, design, or commercial are the most common backgrounds.

The APM works with a product development team under the leadership and mentorship of a product manager, where they would focus on learning the full breadth of the Product Manager role whilst on the job.

Typically an APM would need 3-5 years of experience before progressing to the next level as a Product Manager.

Product Manager (PM)

The most common job title of a product manager can span a wide range of experience, responsibility, and skills. Broadly this is someone who operates independently, leads the work of a product development team, and is responsible for a product line or customer journey. Because it’s the most common title, it’s important to consider what product they manage.  For example, if they’re a product manager for Facebook’s news feed and impact billions of users, they’re probably more senior and experienced than a product manager at a brand new startup.

To be clear, the Product Manager is fully accountable for the success of their product line, so as well as defining the product vision, KPIs, strategies and product roadmap for their product line, they would be part of an Agile team managing the product backlog and working with the engineers to execute the product backlog items (PBIs) and test hypothesis.

For some insights on the Product Manager role see ‘How do you Become a Product Manager?’ by Liam Smith and discover what it is that Jase Clamp believes really makes a Product person in ‘What’s in the DNA of Product People?’.

Similar to the APM role, after 3-5 years as a PM you can expect to take the next step to become a Senior Product Manager.

Senior Product Manager (SPM)

A senior Product Manager does the same thing as a product manager but has a senior title either in recognition of their contributions, the relative importance of their product, or reflects the fact that they also spend time coaching product managers. The Senior Product Manager is hands-on with a product line and also has some line-management responsibilities.

Once you’ve been a PM/SPM for at least 7 years and at least 2 of those has involved line managing/coaching other PMs, then you’re ready to take the next step up to the Lead PM or Head of Product of a specific product line eg. Head of Product – Rewards, Head of Product – Engagement or Head of Product- Gaming.

Principal Product Manager (PPM)

This is a newer role, and usually a very senior product manager who is responsible for a critical product in the company. This can be equivalent in rank to a Senior Product Manager through to a VP Product. The difference is they are not managing other product managers at all — they are simply exceptional product managers who want to stay hands-on and leave people management to others.

In many ways, this is similar to the Architect track in engineering (in contrast to the CTO track), and something we should encourage more. Just because you’re a great product manager and want to advance in your career, it doesn’t mean you should have to move away from being a hands-on product manager to a leader of other product managers. Some people are just better suited to one path than the other. Recognising who is great at leadership and who is great at building amazing products is equally important and valuable to an organisation.

Product Lead / Lead Product Manager / Head of Product – [product line]

This role is more common in larger companies with more products and management layers. Whilst this role does focus on managing other product managers, a significant amount of time would be spent supporting Product Managers with their product line vision, strategies, market analysis and execution, helping improve the product organisation structure, leading Lean initiatives to reduce waste across the business and work on cross-product line strategies.

At this level you’d have been exposed to working across multiple product lines, line management/coaching PMs and being even more dynamic, so after 3 years of being at this level, you’d be ready for the Product Director / Head of Product role.

Product Director / Group Product Manager / VP Product / Head of Product

This is where the role starts to change. It goes from an individual contributor who manages a product line and works hands-on with engineering and design teams, to someone who has stepped back from the day-to-day to focus on leading other product managers and working on alignment. This is where soft skills around people management become a critical part of the job.

After being a Product Director for at least 3 years, it’s time to take the final step up to be the Chief Product Officer.

Chief Product Officer (CPO)

A Chief Product Officer is the most senior product person in an organisation. They usually manage more than one team of product managers and represent product in the C-suite or management team. They’re responsible for overall product strategy and alignment within their teams and with other parts of the organisation.

The difference between a VP Product and CPO in smaller companies isn’t huge, and the title is used interchangeably for the most senior product person in the company. But in larger organisations that have both roles, we can again borrow from our engineering friends to clarify the difference. The VP Product is responsible for the team, the processes, and getting things done, while the CPO is responsible for the overall product vision, product architecture, and overall organisational alignment.

In ‘Where Does Product Fit? What’s Being a CPO Really Like?’, Zoopla’s CPTO Dave Wascha shares his take on the reality of the CPO role, where Product fits within the organisation, what skills product managers need to be successful, and more. You can also learn how Ashley Fidler went from a PhD in Linguistics to a CPO at Eigen Technologies in her instalment of How I got my job.

One size does not fit all

Most companies don’t need all these tiers of course, so it’s important to think about how this fits into your organisation. At a startup, you might have a single Product Manager. As you grow, a couple of Product Managers could report to a Head of Product/VP Product. Only as the company grows and the suite of products grows do you need to consider more layers. As with anything else in product, these team structures and tiers should be aligned with customer needs. This way, you can incentivise and organise teams in alignment with your company goals.

Structure = Clarity

Having clear and common structures for product management job titles in our teams will help us all better understand our careers, roles, and teams. This structure should provide the right foundation for you and your teams to ask: Do your team’s titles accurately reflect their jobs? Are they clear enough that applicants looking at your open vacancies know what you’re hiring for and if the job is for them? Or do you need to rethink your structure to maximise clarity?

Once you have validated that your product has market fit and you begin to scale, it won’t be long until the product roadmap starts to fill up with valuable product iterations. Soon after that, there will be an appetite from the c-suite to understand how the value on the roadmap can be delivered sooner.

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

In order to deliver more value sooner and 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 Lean.

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)

  • Managing the Lead Product Managers (although there is often a Product Director to help with this)
  • Handling the high level product vision for the overall product

Head of/Lead/Senior Product Manager of the Product Line(s)

  • Market analysis
  • Product organisation improvements
  • Leading Lean initiatives to reduce waste across the business
  • Cross product line strategies
  • Customer analysis
  • Qual / Quant data analysis
  • Product line strategy
  • Product vision
  • Product roadmap
  • Capacity planning
  • Coaching / supporting product managers

Product Manager / Associate Product Manager working with the Development Team within a Product Line

  • Contributing to the product vision, roadmap and strategies
  • Qual / Quant data analysis incl. conducting customer interviews
  • Backlog prioritisation
  • Epic / feature scoping
  • PRDs
  • Requirement workshops
  • User story definition
  • Detailed acceptance criteria
  • Backlog grooming
  • Sprint planning
  • User acceptance testing
  • Retrospectives
  • Daily stand-up
  • Live product support

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

In order to have the necessary focus on the product vision, managing stakeholder expectations, quant/qual data analysis, prioritisation and product strategy, it’s important that when adding additional development teams to the product line that the product manager gets more support too, or otherwise the development team could easily fall into the build trap and start delivering features which customers don’t want or need.

Vision

It’s worth spending time creating a compelling vision statement because it’s something that will be repeated over and over again as it’s the key driver to drum up excitement, passion, investment, confidence and trust that the product direction is aligned to the business, solving a real problem and then, in turn, delivering significant value for the business and customers.

First things first, craft your vision statement which should only be one clear sentence, wherein a nutshell it should explain what you’re looking to deliver, to who and why:

Vision statement

Then create a product vision board specifying who the target market is for your product, problems the product solves, clarifying what the product is and how the product is going to benefit the business and customers:

Vision board

Lastly, having a vision diagram is a great way of providing stakeholders and the business with a visual image of the status of the product capabilities of where you’re at with the product today and where you’re heading. Having colour coding for ‘live’, ‘in progress’, ‘planned’ and ‘to do’ would cover it – there are plenty of mind map tools to help you visualise your product, one of which is Lucidchart which comes as a plugin for Confluence also. It’s important to keep the product diagram focused on high-level features rather than detailed technical solutions around systems as that would be more of a technical architectural diagram:

Vision diagram

Having a solid product vision isn’t just to help the business allocate resource, but it’s also essential for the development team to know exactly where they need to head and why.

Once you have a compelling product vision, it’s time to find out how to get there by creating your VMOST!

Strategy

VMOST = Vision, Missions, Objectives, Strategies and Tactics


Each product line 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 framework of showcasing what these are in a clear and concise format.

Vision: An inspiring statement which typically should only be one sentence, wherein 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: To achieve the product vision, there would be multiple high-level missions you need to go on – what are the biggest problems that need solving before achieving the vision.

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

Strategies: Initiatives that 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 managing the product VMOST, it mustn’t happen in a silo, as it takes collaboration with the rest of the business especially stakeholders/BI/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 evangelise this in a passionate way across the business and perhaps print it out on A0 to sit near the Product/Agile Team on the wall, so it can always be top of mind.

Good luck in creating your VMOST!!

Once you’ve defined a compelling Product Vision and VMOST, you will need to map out the ‘what’ and ‘when’ and the Product Roadmap is a great way of visualising the journey.

The Product Roadmap is also a good way of managing expectations with stakeholders, a great visual to collaborate over and view dependencies, as well as giving assurance to the engineers that you do have a well thought out data-focused plan rather than changing your mind daily based on who shouts the loudest.

Key points of a Product Roadmap:

  • It should be at a high-level eg. Epic, feature or iteration level – Epic level is a preference as then it maps nicely to the teams’ product backlog items (PBI) under the epics.
  • It needs to include dates spanning the next twelve months whether monthly or quarterly.
  • The bars on the chart show when items start and when the development will be complete (live hidden).
  • One of the most important things is to educate development teams and stakeholders that the drop dates are an intent (not commitment) of focus/delivery and that things will change, so it’s advisable to avoid spending significant amounts of time making each item exact, as the desire from the business would be to have a rough idea of the twelve-month view rather than knowing whether something starting in six months will be delivered exactly a month later than that for example.
  • The roadmap needs to be easily accessible by anyone in the business where they can use their network login and can also access it from outside the office eg. on the train – if it’s hard to access, people just won’t view it and assume there’s no plan.
  • It needs to be updated frequently – if it’s regularly out of date, again people just won’t access it.

Product Roadmap examples

Roadmap sample 1

Roadmap sample 2

The most important purpose of the Product Roadmap is for you to provide a sign of intent for when product items will be delivered over the next twelve months (your journey to reach your goals/product vision), with the keyword being ‘intent’ here ie. Not an exact drop-dead delivery date. Product Managers with experience of the teams’ velocity could use gut feel also which is acceptable or rough t-shirt sizing from the lead developers, rather than dragging the dev teams away for hours/days to roughly size big pieces of work which will either 1. Change anyway and 2. Be extremely inaccurate as unknowns result in estimates going through the roof.

This book was a fascinating read where Grove talks about how he pulled off the greatest transformation in the history of Intel: moving from the memory business to microprocessors more than a decade after its founding.

During his tenure at Intel Corporation, he described the different reorganisations that the company went through, with the only one which was effective – which just about every large company or enterprise that he knew was organised was in a hybrid form, which consisted of mission-oriented departments. This reminding me of product lines.

Although it was published over 25 years ago, the management practices are timeless, where Grove touches on the negative impact of ‘managerial meddling’ (disempowerment) and he talks about productivity, work simplification and leverage with the goal to work smarter, not harder!

As Grove says “..the single most important sentence of this book: The output of a manager is the output of the organisation units under his or her supervision or influence”.

The key to survival is to learn to add more value, which is ultimately what this book is about.

A classic book on management, which I’d recommend.

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”.”

Really glad I bought this book by Noel Tichy – the inspiring stories and explanations gave me plenty of opportunity to self-reflect about my leadership capabilities, which has explained a lot and given me confidence that I’m heading in the right direction.

Tichy explains how organisations that have a Leadership Engine win because they have leaders at every level who teach others to be leaders. Teaching and learning are at the heart of these organisations.

“A crucial element in this process is that winning leaders and winning companies use mistakes as coaching opportunities rather than causes for punishment. Treating mistakes as learning experiences, in fact, is one of the ways in which winning leaders encourage others to develop edge and take the risk of making tough decisions.”

I’d definitely recommend this book.

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 principles and guidelines, that the ultimate objective is to deliver customer value/the product vision efficiently and competitively.

To help avoid losing sight of this objective and falling into the trap of obsessing about the intricate details of the frameworks too much, gap analysis must be 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

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.