Please enable JavaScript.
Coggle requires JavaScript to display documents.
How to help product managers become more than glorified project managers…
How to help product managers become more than glorified project managers
agile
deliver work in regular cadence
'we value responding to change over following a plan'
Agile manifesto
born out of frustration - software development, uncertainty and complexity hard to nail in advance -
*work in short cycles/sprints, pause to check progress
and see if need to change direction for next sprint i.e. be agile*
Dev Ops
Shipping code at pace.
Rapid delivery of code and rapid feedback
SAFe Scaled Agile Framework
Agile manifesto speaks to team level - at scale - can lead to chaos. Framework to address this.
lean start up
Should we build it? If yes can we build a sustainable business model around it
Steve Blank and Eric Ries
short cycles to run experiments,
preserve, pivot, kill. idea altogether. Measured through customer behaviours. Did they indicate they want and will pay for it...re. a feature....
Adoption by nimble start up companies/ entreprenuers
MVP
Ans 2 qs. whats the
most important thing we need to learn first,
whats the
least amount of work
we need to do to learn it.
Learnings should inform the next cycle of work
Identify scope of the release and shepherd towards the outcome. What should we focus on?
innovation labs
Clay Christensons book
Innovators dillemma
standalone business units
immune to BAU, charting the future
No P&L
Creative
*can lack strategic mandate, clear path to transition a product idea once validated, into an integrated production path for the broader org.
- this isolation can yield very little*.
modern offices, open workspaces and beanbag chairs.
design thinking
working on something of value?
empathetic look at customers
they're building products for, to
understand their core needs
series of facilitated brainstorming exercises to set of solutions that meet those needs, is technically feasible and viable for the business.
Ideo
popularised in 1990s
around for decades
customer empathy hard to find in large companies.
Designers 'design' sessions to brainstorm etc to increase team's empathy
outputs, sketches, post it note clusters, whiteboard scribbles.
At best - build shared language and common sense of purpose for the project.
At worst, perceived as waste of time that could be used to write code.
Continuous lifecycle tool.
Which process is right?
work in short cycles
software and people hard to predict
how will people react to the changes?
Pick new idea/ practice and try it
experiment for 2 sprints. Fail let go. Succeed, keep and run at scale.
e.g. experiment to increase customer exposure
every 2 sprints the whole team goes out to observe customers using your product for a half day
specifics of the outing, planned usability tests or customer interviews, observations, irrelevant
Goal to get members of the team not usually in contact with the customer to do so regularly
take small steps
hold regular retrospectives
the heart to continuous improvement
regular opportunity for team to consider current practice, evaluate efficiency and determine how to progress
Initial ones uncomfortable - can feel like venting sessions
those using it regularly can generate tonnes of improvement material and a sense that very little is getting better
e.g. end of sprint 1 hour review with whole team
review what worked well in the cycle, what didn't, and commit to improving 1 or 2 key things each time.
will feel ackward at first, then people will open up more freely, to address issues hurting their collaboration
If this isn't happening get an outside facilitator for these meets, to probe for root causes and solutions.
put the customer at the centre of everything
customer is the person who has to use the product
without them there's no business, team, product
e.g. if you're struggling to get alignment as a team - focus on CUSTOMER VALUE
if team debating what to work on, how much more time to spend on something or whether products heading in the right direction
Ask the following questions regularly: how do we know we're shipping something users care about? - to establish whether we've got a good feedback loop with customers - don't know? critical gap...how do we find out?
Do you need to go out in the
field
to meet customers?
Do you need to implement an
analytics
system?
Is there a
conference
you can go to where your customers regularly congregate?
How does all that affect what we prioritise?
Get the
feedback loop
in place and incorporate into decision making process in a timely way
Regular customer development debriefing sessions...
Definition of customer can vary with practice...Lean and design thinking - person buying or using the product is the customer....Agile the business is the customer - -which is NOT right.
Go and See - go to the gemba
Japanese phrase - born from lean manufacturing movement
get managers out of offices and onto the manufacturing floor, to see how teams were working
Same true for software teams
regularly walk around, talk to the teams
ask them whats working and where they're struggling
bring learning back to the management meetings and share with colleagues
patterns yielding good outcomes should be amplified and scaled
patterns causing problems diagnosed and remedied or stopped
working from recipes - a good place to start! But will morph to needs of your enterprise
**
Balance product discovery with delivery work
by only testing high risk hypotheses
teams rarely tasked to just learn
same teams have to ship product to market
product discovery work can be seen as a block to shipping code
brainstorming sessions...waiting for the research to be done....? Why are we testing everything?
exacerbated when each team wants to practice their flavour of product discovery, product setting one set, designers another, engineers wanting to get out of all - to get on with writing code
teams can't and shouldn't test every task I their backlog
some assumptions in backlog are always riskier than others; prioritise these ones based on their perceived risk and perceived value - everyone weighs in on risk as each item can have different types of risks for different teams..e.g. a tech risk (engineer) design complexity (designer) market risk (tangential audience)
Product Mxs should be good at providing competitive and market analysis - understanding
High risk High value items should be only ones in product discovery efforts
id the high risks, id what most important thing you need to know about them is - then use the best discovery technique for the job to learn that
e.g. technical risk most important to verify
a tech spike - an agile technique that time boxes a technical research effort...is right way...?
e.g. need to know an idea has real value before you build it
A B test. A landing page test. Classic lean start up tool.
e.g. unsure the problem you're solving actually exists for your customers
contextual site visit - design thinking tactic, might work.
limiting product discovery to riskier items - ensure team delivering features while it's learning - using the tool you need to max your learning in the time you have.
Do less research more often
user research - design teams tool, around a long time,
not subtle - large hammer to crack small nut
e.g. regardless of what you needed to know, 2 days off site, candies, 12+ test participants, broad array of team members dipping in and out(Madmen two way mirrored room). Moderator with testing script - id every major issue usually within the first 5 participants. Others - no additional value. Made to feel a colossal time waste. They were right!
Recc: Contiuing to practice user research with a cross functional team in attendance.
Do less more often.
instead of testing 12, test 3.
take the learning from 3 then do the test again next week.
don't go off site - maximise your attendance by keeping it in the office
broadcast findings broadly immediately after the test
hence show value of exercise, reduce commitment for participation and the cost - increases organisational buyin for this classic product discovery technique
Can make attendees lose faith
work and train as one balanced team
Agile fall - waterfall development with agile language
disciplines starting to speak a common language but can continue to work in silos, handing off to each other - not working on the same timgs at the same time.
actively moving away from this for yrs
to combat, think about how you staff projects
Atomic unit of planning for a project is 'the team'
designers, software engineers, and product managers
combined provide all the elements of the project
independent, autonomous, empowered to make decisions based on the evidence product discovery work uncovers
structured this way - it doesn't make sense to train them all in different ways - no difference in the cadence of engine, degin, prod mg, on a balanced team.
Their efforts coordinated, aligned and targeted at the same learning and delivery goals
balanced teams use the best parts of agile, design t, and lean and apply as needed tightly collaborating
Radical transparency
Some team members will have trained in different methods.
when tasked to take on a new way of working - people can struggle
they've learned to their job a certain way and they're good at it
why should they change? how will it make them better at their job?
As new processes get rolled out - ensure its clear why you're trying something new.
let people see how the process plays out with other teams
hold open retrospectives - so others can see where a new process struggles in your company
Be clear about what success looks like - and make sure everyone's aligned to that criteria, and identify how you'll measure it
If certain aspects don't fit in your org. be clear as to why you're abandoning them - and what you'll do instead
post success metrics in public places around the office - and show how progress is/ isn't being made against those metrics - e.g. using real-time monitors or print out the state of a metric everyday you walk into the office, indicate how it changed from yesterday - and post that all over the office - (wipeboard the big short.....)
In all cases default to open
Review your incentive structure and performance management criteria
this is probably the most important criteria for ensuring you team chose the most productivity amalgamation of these philosophies to work with
teams optimize the work they're incentivized to achieve...
Velocity
means getting more features out to market
Learning
they'll build better product discovery processes
these same incentives have to be reflect in your co. performance management criteria
to build collaboration in learning
employees have to be assessed on the efficacy of their collab and their ability to build cont. learning into their work.
e.g. velocity is only rewarded if user satisfaction reflects value in the feature shipped
knowing their co. rewards this behaviour will encourage staff to think about which tool from which philosophy will be help them achieve that.
Make Product discovery work a 1st class citizen of your backlog
common symptom - the work that gets visualised is the work that gets done
Agile has clear direction on rituals and ceremonies that visualise the work
Why their work is often displayed in JIRA or other project management tools
No clear process or ritual linked to learning work
delivery aspect of agile get visualised, measured and executed
Here, agile wins as the value activity of lean and design rarely find their way into the same tools as the agile activity.
this marginalises the effort, and allows it to be cut in the event of a time or scope cut.
team members then try to fit in discovery tasks in the cracks of their calendars
To change this we MUST: make it 1st class citizen, must be visualised along with the delivery tasks, it must prioritised against them and assigned to specific members of the team.
It MUST be tracked like delivery tasks, and the implications of the discovery work have to be taken seriously.
learning will id gaps in backlog or poor prioritisation decision, so changing plans in reaction to these learnings is AGILITY. It's the whole reason to adopt this way of working - and the key to building responsive teams and organisations.
Bottom line - your customers don't care what you practice. They care about great products and services, that solve meaningful problems for them, in effective ways. The more you focus teams on satisfying customer needs, collaborating to create compelling experiences, and incentivising them to continuously improve, it won't matter which method they employ - their process will simply be better.