How Product Managers can help stop companies from screwing up technology - Product Tank 15th June 2015
•Télécharger en tant que PPTX, PDF•
24 j'aime•3,449 vues
If you're not a technology business, technology can still be hugely important. You're probably building your own technology. Here are some tips on how to avoid screwing up technology, how product managers can help, and why good or bad tech can make or break a product team.
Recommandé
Contenu connexe
Similaire à How Product Managers can help stop companies from screwing up technology - Product Tank 15th June 2015
Similaire à How Product Managers can help stop companies from screwing up technology - Product Tank 15th June 2015 (20)
Dernier
Dernier (20)
How Product Managers can help stop companies from screwing up technology - Product Tank 15th June 2015
- 1. How to avoid screwing up technology (and how product managers can help) Paul Lomax, CTO, Dennis Publishing @PaulLomax
- 2. Me
- 6. So, how do you do tech if you’re not a tech company?
- 7. JFDI!
- 8. The problem with technology is people.
- 9. Buy, build or rent? “If it flies, floats or fornicates, always rent it.. It's cheaper in the long run.” – Felix Dennis (1947-2014)
- 10. Enterprise
- 12. Writing code should be a last resort.
- 13. "We'll just build our own..." How much work your developers think is involved. Stuff they haven't thought of.
- 14. Pragmatism (Your job is to stop this!)
- 15. “You’re not here to write beautiful code. You’re here to create business value.” Me, to developers
- 16. Technical debt W User story What was shipped
- 18. The vicious circle of technical debt
- 19. Record all borrowings Agree a repayment plan
- 20. Problem people #2: Customers & Stakeholders
- 22. “I’ll know what I want when I see it…”
- 23. Problem people #3: Product managers
- 25. Product Managers
- 26. Requirements re·quire·ment n. 1. Something that is required; a necessity. 2. Something obligatory; a prerequisite.
- 27. Requirements Discovery Ban ‘requirements’! Everything is negotiable
- 28. As an Account Holder I want to withdraw cash from an ATM So that I can get money when the bank is closed Scenario 1: Account has sufficient funds Given the account balance is $100 And the card is valid And the machine contains enough money When the Account Holder requests $20 Then the ATM should dispense $20 And the account balance should be $80 And the card should be returned Story: Account Holder withdraws cash Scenario 2: Account has insufficient funds Given the account balance is $10 And the card is valid And the machine contains enough money When the Account Holder requests $20 Then the ATM should not dispense any money And the ATM should say there are insufficient funds And the account balance should be $20 And the card should be returned Scenario 3: Card has been disabled ... Behaviour Driven Development (BDD) http://dannorth.net/whats-in-a-story/
- 29. Be lean & agile.
- 31. Beware half-arsed agile Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Whilst the items on the left sound nice in theory, we’re an enterprise company, and there’s no way we’re letting go of the items on the right. www.halfarsedagilemanifesto.org
- 32. 1. Eliminate waste 2. Amplify learning 3. Decide as late as possible 4. Deliver as fast as possible 5. Empower the team 6. Build integrity in 7. See the whole Adopt lean principles
- 35. ● Ban 'requirements'. Focus on objectives. ● Address technical debt & a repayment plan. ● Communicate business value through BDD. ● Wield a pragmatism stick: beat developers and stakeholders with it. ● Help developers spot the icebergs. ● Avoid waste, prototype, spike, test & learn. ● Control scope, focus on a quality MVP. ● Kanban! Kanban! Kanban!
- 36. Paul Lomax Chief Technology Officer, Dennis Publishing t: @paullomax e: paul_lomax@dennis.co.uk
- 37. Picture credits Men's Fitness: http://www.mensfitness.co.uk/ Silicon Way: https://www.flickr.com/photos/iamadonut Code: https://www.flickr.com/photos/110751683@N02/ Donuts: https://www.flickr.com/photos/cobalt/ Post-it notes: https://www.flickr.com/photos/roxocubes Ship-wreck: https://www.flickr.com/photos/102537907@N03/ WTFs/min: http://www.osnews.com/story/19266/WTFs_m Tech debt matrix: http://philippe.kruchten.com/ Kanban: http://commons.wikimedia.org/wiki/User:Jeff.lasovski XKCD on Arbitrary Condiments: http://xkcd.com/974/ Mastercard: https://www.flickr.com/photos/shuttercat7 Technical Debt https://twitter.com/khellang Product Management Venn diagram: http://www.mindtheproduct.com/ Iceberg: http://ralphclevenger.com/portfolios/earth/ I'll Know What I Want When I See It: http://sharpsuits.net/Home Baby Squirrels: http://www.flickr.com/photos/_crazysanman/2391480258 / Lean Startup: http://lean.st/ Agile Manifesto: http://blog.theworkinggroup.ca/ Dilbert on Requirements: http://dilbert.com/strips/comic/2006-01-29/ MVP: https://twitter.com/jopas
Notes de l'éditeur
- How to avoid screwing up tech. What part product managers have to play. Why it’s important, even for non tech
- 15 years leading product dev, PM, UX & Tech. Few of hundreds of brands. Digital guy in legacy business. Impatient. Would be a chef
- Dennis well known in mag industry. Famous for Maxim. Now The Week, Viz, Cyclist, Men’s Fitness, Autoexpress etc.30 brands, 10 digital pure play = 60%. Digital revenue 2x in 5 years
- Founded 40 years maverick Felix. How to get rich book, Best selling living poet.Maxim, computer mags, but no mobile. Was worth £500m ST rich list.
- Left to charity established before death. Plans UK’s largest contiguous forest. Over 1m trees already. Huge project. Timespan 50 years for planting. 100 year biz plan. DPL still commercial. Ambitious
- Not tech but tech at the hear. 3 pillars. Lessons for tech & non the same. Lack of tech people in senior positions = work harder at it, push change. One tip:
- Just fucking do it. Easier to seek forgiveness than ask permission. Change bottom up. Takes time. Do try get buy in (read Lean Startup). You will step on toes. Even better, hire someone to JFDI.
- Ultimate it’s people who make tech bad. As PMs ability / responsibility influence. Make or break PM team. Three main groups: devs, customers/stakeholders, PMs
- First most important question for non-tech. Playboy mansions Felix built but if it flew floated or fornicated he recommended renting. Often same for tech. Is it your core biz? Competencies? Also don’t build from scratch. The Week app at launch - no iOS skills so found partner.
- Unless buying starship, avoid Enterprise. Synonym for expensive, inflexible. No pricing. If renting (ie cloud/sass) go for: API and UI. Usage, integrations. Tip: look at good app’s integration pages for good apps( eg slack)
- If building, you’re going to need devs. Pointers from experience of both sides
- Sounds odd, but code proliferates. Every line of code needs to be maintained. If building, follow Best Practice. Do ‘Joel test’: Version control, automated testing, etc
- How much work devs think involved. How much they haven’t thought about. Your job as PM to spot ice below water. Collaborate during estimation, ask Qs.
- Conversely. Don’t leave devs to own devices. Question assumptions, may invent needs. Say no - you aint gonna need it (yet). Give your estimate in planning. Collaborate, find path least resistance.
- Not here to write code, create value. Don’t call them devs, engineers, solutions. Stand on shoulders of giants, use open source. If something is just as good, use it. Are your differences really required?
- Tech debt work needs to be done to be considered complete. Like any debt, it can be good or bad. Good if an investment - to ship now. Bad if over spending, not paid off.
- You know you have tech debt if high WTFs per minute.
- Tech debt vicious cycle. Accumulates if not repaid. If cost of making changes exceeds value of those changes, you have a big problem - product team redundant. If you can’t pay down, declare technical bankruptcy, start again.
- Not a silver bullet but will help. Record every kludge, missing docs / tests. Put tech debt on backlog.. Repay with sprints or swimlanes. Prioritise with devs. Skeletons. Future.
- Should be meat and drink for PMs, dealing with customers & stakeholders. If you don’t manage them they can make you screw up your tech
- I need to get your requirements. What does the software do? That depends on your requirements. Can you design the software to tell me my requirements?
- Customer stakeholders don’t know what want. Rework costs time money, makes tech debt.. Thrash out in wireframes, prototypes, spikes. Coding is not carving in stone, but not far off - makes it hard to architect, which creates tech debt.
- And finally, the product managers!
- Actually you should be part of the solution not part of the problem. You have the power
- If you can wrangle all these three and communicate effectively. Half the battle
- Who does ‘requirements gathering’? Ban the word requirements. Implies stuff is obligatory. Everything is negotiable.
- Define objectives, problem to solve. Don't try and provide solutions. Look for pain points. Look for opportunity. Latent needs. Have vision. Rolodex doesn't think he needs a CRM.
- Solution to afore mentioned problems. Talk in itself. Go read up, do it. Way of documenting what software should do. Non tech docs, but automated tests.
- Kind of goes without saying? PMs can drive it.
- Don’t mean this kind
- So while the items on the left sound nice in theory, we’re an enterprise company, and there’s no way we’re letting go of the items on the right. Agile != SCRUM. Agile != Lean.
- Go read The Lean Startup, Eric Ries. Highlight: decide late as possible. PMs make assets when needed. Not too early. Waste. Out of date. How do you know when Just in Time?
- Who’s doing Kanban? Go do it. Uses board like Scrum, but pull not push. Post-it moves = signal to do something. Limit WIP, stops half-finished waste. If doing KB, don’t put up epics as they get stuck.
- Saved most important slide to last. Massive impact on tech quality. Goes to shit if breadth not depth first. Better half a product than a half arsed product. Complexity causes problems so keep it simple. Define done! Include docs, tests, etc. Scope control the most important thing.
- Ban 'requirements'. Focus on objectives. Address technical debt. repayment plan. Communicate business value thru BDD. Wield a pragmatism stick, beat developers & stakeholders. Help developers spot the icebergs. Avoid waste, prototype, spike, test learn. Control scope, focus on a quality MVP. Kanban! Kanban! Kanban!