If you focus on these eight concepts you WILL build better products. It will not be easy, and it will not be instant. You’ll probably get a lot of pushback and ruffle some feathers, but I promise that your product/service will benefit.
As product development teams we spend a great deal of time looking for “the answer”. We often adopt methodologies as a safety blanket, and then lose faith when the situation changes. Sure, I’ve provided some examples. But your teams are smart! Let them experiment with the how. Paint these broad goals and let them lead you.
Build a better product by …
1. Shortening the distance between the product development team (UX and engineering) and the customer
For example …
- Team fieldtrips to visit customers onsite
- Biweekly lunch and learns with moderated customer discussion
- Allow any front-line team member to pick up phone and call customer
- Hire full-time UX researchers, with goal to share research and engage others in research Why? With each hop you lose signal. Efforts to filter this information to make it more “actionable” are largely ineffective
2. Accelerating any form of learning about your customers, market, technology, self, team, and organization
For example …
- Regular team retrospectives, outings, and conversations
- Voice-of-customer programs, access to accurate usage metrics, regular presentations on competitors and trends
- Pairing, mob-programming, mentor program
- Offer experiment-design training, and share results broadly
- Celebrate learning! Share broadly. Share visibly Why? Your team’s collective learning is your organization’s foremost asset. Left unshared, it depreciates almost immediately
3. Watching a real user use your product to get their job done
For example …
- Moderated and unmoderated usability tests
- Diary studies with screen-share (e.g. always-on GoToMeeting study)
- Session recording, click-stream analysis Why? To get out of your own head! No use is arguing about whose guess is better
4. Making it possible to deliver software more fearlessly and with less drama
For example …
- Test driven development, automated testing, CI, “stop the line” mandate (with no repercussions)
- Feature flags, beta groups, prototype framework
- Invest in DevOps Why? If you work scared, you’ll take no risks
5. Reducing the number of dependencies and constraints
For example …
- SOA, plan for obsolescence and change vs. hardening and future-proofing
- Teams aligned around distinct value streams vs. organized around architecture or skill-sets
- Fewer promises to customers, and other stakeholders (internal and external)
- Late binding of teams (vs. pre-assigning epics to teams months in advance)
- Just-in-time planning, co-design, design sprints, etc. Why? You can’t move quickly with your hands tied. And if you try, you’ll have mediocre results
6. Promoting diversity, and engaging the minority viewpoint
For example …
- Diverse hiring teams, self-selecting teams and projects, voluntary team rotation
- Tailor activities to different communication and learning styles
- Leaders speak last. Coach on listening and communication skills (while respecting diversity)
- Anonymous surveys (if safety level is low)
- Ritual dissentWhy? If everyone thinks the same and is forced to agree with the loudest voice, you’ll never explore different perspectives.
7. Fostering creativity and freedom to explore and experiment
For example …
- Describe the end-goal vs. a particular solution. In other words, promote creative solutions for “normal” work
- Teams self-select stretch innovation project after completing “normal” feature
- Get individuals out of functional silo (UXers code, engineers design)
- 10% time, idea marketplaces (Tinder for collaborating on projects), co-design with customers Why: If you are 100% delivery focused, you’ll eventually hit the point when the luck runs out. We all crave a sense of impact and get a buzz from trying something new. Bonus: this is how you innovate … not some lab or hack day.
8. Bridging silos
For example …
- All employees spend time in support queue
- Marketing and sales engaged in group design activities
- Front-line teams present to senior management (not a middle-person) Why: Silos inhibit the flow of information.