"Stop making excuses a culture first approach to product centricity" by Jordan Brown
4 likes832 views
The document discusses the importance of a culture-first approach to product centricity, emphasizing the need for lean product design and strategic value delivery within organizations. It outlines practices, principles, and communication strategies that foster a collaborative design culture, enabling teams to prioritize customer needs and innovate effectively. The document also highlights challenges, such as silos and tech debt, while promoting continuous learning and alignment between IT and business goals.
"Stop making excuses a culture first approach to product centricity" by Jordan Brown
- 1. STOP MAKING EXCUSES START DELIVERING VALUE A CULTURE FIRST APPROACH TO PRODUCT CENTRICITY
- 2. 2 OUR AGENDA _ Introduction _ Story Time _ What I mean by Lean Product Design _ Culture First _ The Playbook _ The End
- 4. “CDAF” “CDAF” 4 WHO ARE YOU?! WHY SHOULD I LISTEN TO YOU?! -A Reasonable Skeptic
- 5. 5 JORDAN COURTLAND BROWN He / Him / His 6 Years in Nonprofit Strategy 2.5 Years at ThoughtWorks Lean Product Transformation / Product Strategy / Product Management
- 6. STORY TIME 6
- 8. MOBILE ADS UNIFIED USER EXPERIENCE PROMISE OF VALUE What are we doing next that delivers value? POD 1 POD 2 POD 3 POD 4 How much are we investing? GROWTH + SUSTAINABILITY STRATEGIC GOAL STRATEGIC GOAL What does the organization need to achieve to realize the Vision? WHEREVER WHENEVER MOBILE DESKTOP What’s our strategy for achieving that Goal? ADVERTISING PLATFORM $$$ Users+ Advertisers+ Mobile+Ad $$ Ads + Mobile Ads + M. Imp + M. Eng + VISION What is our destination as an organization? “People use Facebook to stay connected with friends and family, to discover what’s going on in the world, and to share and express what matters to them.” 8
- 9. HOW DID THEY DO IT ? 9
- 10. 10 PRODUCT CENTRICITY IS A CULTURE OF DESIGN
- 11. 11 Building the Right Things Building the Things Right IMAGINE LEARN DESIGN TEST CustomerNeed TacticalAction
- 13. CULTURE PRINCIPLES CULTURE OF DESIGN PRACTICES TECHNIQUES VS OPEN ENDED QUESTIONS, MANY POSSIBLE ANSWERS. Given a Principle… How do we approach this now? Could we be better? What would good look like? This month? In six months? How will we know we’re getting better? TERMINAL QUESTIONS, YES OR NO ANSWERS. Given a Practice / Technique… Do we or don’t we? Are we or aren’t we? Best practice or not? N/A, we checked the box or didn’t. N/A, we checked the box or didn’t. 13
- 14. “We have a truncated process that inhibits our ability to work holistically within an overall Vision.” “We have identified areas of short-term capability growth and improvement .” “We are beginning to blend areas of the business around a product strategy.” “We have become an organization designed for purpose, delivering value understood and owned by all.” CULTURE OF DESIGN EVOLUTION OF DESIGN CULTURE 14
- 15. HOW CAN WE START AN EVOLUTION IN OUR CULTURE? 15
- 16. PLAYBOOK FOR A DESIGN CULTURE 16
- 17. 17 VALUES WHY > WHAT + HOW OUTCOMES > OUTPUTS BOUNDARIES > CONSTRAINTS We need to implement Paypal checkout! Do we know what our customers are hoping to accomplish? How’s that going? X ✔ Our Velocity went up! We completed 10 more stories than last week! We delivered this business value, and average cart value went up 10% X ✔ All stories need to be written, in Jira, in this format… We have both a physical and digital backlog, Devs understand stories, and Cycle Time is low X ✔ BETTER > PERFECT We can’t do User Testing—we don’t have external access to staging set-up and that’ll take… Marketing got us in contact with 5 user’s and we’re doing screen share over Skype X ✔ Low Checkout Conversion? What Did We Accomplish This Sprint? Are We Working Effectively? Will We Validate This With Real Users?
- 18. 18 BEHAVIORS DISCOVER Researching customer needs PRIORITIZE Selecting the best place to invest PROTOTYPE Iterating & user testing solution ideas MEASURE Identifying a minimum viable product (MVP) SCALE Grow successful MVPs into products ? ? ?? ? ? ! ! ! MVP 2 3 4 5 6 7 1 MVP+ SPRINT RETROS TEAM WORKFLOW REMOTE COLLABORATION A FEATURE PRODUCT METRICS
- 19. 19 NORMS NOTHING IS ABSOLUTE—EVERYTHING IS NEGOTIABLE This is a HYPOTHESIS DRIVEN model—we discover new truths, things change, and so do we. We try new things. If something stops being useful, it’s gone. Everything in service of the OUTCOMES. Nothing for it’s own sake. EVERYONE A PRODUCT OWNER—EVERYONE A DESIGNER DESIGN WITH THE USER MEASURE EVERYTHING AUTONOMOUS + ACCOUNTABLE We own the outcome—the WHY, and AMAIRAP the what and how of that is totally up to us (Boundaries vs Constraints). That said, WE are accountable for our choices—they’re made intentionally, backed by reason, logged, and transparent. Who Tests the Product? Who meets with Stakeholders? Who participates in User Testing? Who Buys Snacks? Who can sketch a Prototype? Who writes a Story? Who does the 3am Release? Whose fault is this? As much as is reasonable and possible, the continuous design of the product will be a COLLABORATIVE endeavor. AMAIRAP the user (internal too) is involved—or the best proxy we can muster. Everyone takes part in ‘How might we…’ Are our Retros useful? Is this Feature valuable? What’s most painful about Dev to Release? How well are we dealing with Tech Debt? What do our users REALLY care about? How’s team morale? Does this make sense? Can we KNOW?
- 20. 20 COMMUNICATION TEAM TEAM ORG USER WHO COMMUNICATES METHOD V A L U E EMAIL PHONE CHAT TELEPRESENCE FACE-TO-FACE HOW THEY DO IT
- 21. LET’S LEAVE IT AT THIS… 21
- 22. HOW’D I DO? Be ruthless. [email protected] @jordancourtland EMAIL TWITTER @jordancourtlandLINKEDIN
- 27. CONTINUOUS DELIVERY BUILD TEST RELEASE CI PIPELINE INFRASTRUCTURE Unit Deploy to CI Env Compon ent Tests Contract Tests Deploy to QA Smoke E2E Tests Manual or Automatic Step Manual Step Deploy to Staging The component tests should live in the same repository as the production code Contract tests are defined by the consumer but should be in repo and pipeline of the provider. The code should be refactored and documented in the same way you would production code, both QAs and developers are responsible for the health of it. Avoid the ‘Broken windows’ theory keep the build always green Smoke E2E Tests Manual Step Deploy to Prod Smoke E2E Tests For mature teams cross functional testing can be part of the pipeline. Initially focus on making them automated and easily runnable.
- 28. 28 LEAN PRODUCT Building the Right Things Building the Things Right IMAGINE LEARN DESIGN TEST CustomerNeed TacticalAction
- 29. 29 DESIRABILITY FEASIBILITY VIABILITY What people need + want What is technically + organizationally feasible What is capable based on our finances/resources LEAN PRODUCT INNOVATION DESIGN THINKING
- 30. 30 KNOWING WHERE TO START VALUE TO MARKET + CUSTOMERS CAPABILITY THE VALUETO PROVIDE PRODUCT / SERVICE
- 31. 31 KNOWING WHERE TO START VISION STRATEGIC GOAL STRATEGIC BET STRATEGIC BET POD 1 POD 2 POD 3 PROMISE OF VALUE STRATSTRATEGIC GOAL STRATEGIC BET STRATEGIC BET STRATEG BET POD 4 PROMISE OF VALUE PROMISE OF VALUE PROMISE OF VALUE PROMIS OF VALUE POD 5 POD 6 POD 7 PO VALUE YOU PROVIDE CAPABILITY TO PROVIDE VALUE ?
- 32. 32 ROOT CAUSE Lack of Engaged Change Management RESULTING EFFECTS BUSINESS IMPACT Preference for comfort zone of role Internalized Delivery Date Pressure Very Limited Delivery + Enablement Timeframe (48 Days) Siloed roles stifling collaboration Knowledge silos Dev+ QA + UAT Silos Learning curve of new stack Prioritization of features vs. quality Low maturity in defect management + QA comms Informal Tech Debt Management Lack of Tech Leadership for Code Standards Expanding Tech Debt Trail Time to Team Alignment on Quality Code Quality Devs Not Writing Tests Early Some unit tests but limited coverageChange was (is) painful Inflexibility of Old vs. New Practices Constraining SOX Interpretation Heavy Reliance on Org Process (Waterfall) VSTS Challenges Incredibly slow access process VSTS Limits CI Possibilities Lack of shared CI Ownership No Mature Build Radiator Frequency of Broken Builds Lack of functional tests in CI Slow to start with Automated Testing Devs not owning functional test @ start Less frequent integration in Higher Environments Functional Tests failing Longer Build > Promotion Cycles Time developing new technical patterns Unfamiliarity of front-end framework Knowledge sharing of dev practices Long refactoring Longer Dev Cycles Reduced Reliability Higher Complexity Less Features Delivered High Complexity in Handoff + Onboarding Time Spent Configuring Visible + Functional Backlog Laborious + Manual Project Reporting BA/Product capacity drain Competition b/w Role work and Practice Stewardship Challenge to cross- functional analysisAddress the possibility vs tax of ecosystem w/ cause and effects
- 33. 33 BUSINESS DECISION Clearly Prioritized Product Roadmap RESULTING EFFECTS BUSINESS IMPACT Evolved IT + Business Capability Scalability with other products and teams— friendly dependency Justification of Investment in Capability Growth Continuous scaling of increased Product value Clear direction for prioritization IT + Business Alignment Meandering delivery pathNo Alignment between Business + IT on value Team is Product- Focused and not Maintenance / BAU Ineffective Teams Less motivated Developers Frustrated Users Evolution stagnates into crushing Maintenance Broken + Disliked Product Attrition of High Performing Talent Delivery against Top Level Business Goals Inability to Attract Quality Talent Business Validation Churn Prioritization Churn Features always trump tech debt Feature rabbit holes to empty value Disjointed and painful User Experience with Product Ballooning tech debt Valuable Features released slowly Cross functional ownership of Product Visible horizons of product lifecycle Collaborative analysis and delivery process Quality baked in early through test- first culture Constant small design iteration w/ Business Highly knowledgeable + motivated team Continuous learning