The Prototyping Mindset - Devoxx.us 2017

The Prototyping Mindset: Rapidly Build High-Value Prototypes

From the world of Lean Startups, the notion of building a minimum viable product, MVP, seems straightforward as a developer. Yet, so many development teams struggle to quickly build these prototypes. A growing list of features cause scope creep, temptations to future-proof lead to over-engineering and your project's launch dates keep slipping. We won't even mention the budget. What can a development team do?

What if we could adopt a prototyping mindset where, as developers, we could distill a product's purpose to its essential features, identify the ideal customer and build a lightweight application to verify it meets their needs, all within a short timeframe?

After years of building product prototypes with this mindset, we've noticed several ways our conventional developer thinking gets in the way. Join us as we examine each one and contrast it against a prototyping mindset. Not only will you be able to guide your team on how to build efficient, high-value prototypes, but you may find this approach benefits other types of projects.

Transcript

1. The Prototyping Mindset Marty Haught @mghaught
7. – Reid Hoffman, LinkedIn founder “If you are not embarrassed by the first version of your product, you’ve launched too late.”
8. Minimum viable product – Eric Ries, The Lean Startup “A product with just enough features to gather validated learning about the product and its continued development.”
9. Why prototype? Fastest, most cost-effective approach Reduces time to market Easily collect user feedback early
10. We prototype because we don’t know if our solution will solve the right problem.
11. The prototyping mindset Keeping your focus on the fastest, most efficient way to validating your product’s unknowns.
12. Keys to prototyping Know the roadmap Focus scope Measure progress Embrace simplicity Avoid feature polishing Understand trade-offs
13. Know the roadmap 1
14. What is a roadmap? A plan that identifies the problem, the solution, and how the product will address those needs.
15. Traditional mindset Accepts the roadmap at facevalue Assumes the business has done their homework Doesn’t question the problem or solution
16. Prototyping mindset Asks about the problem and solution Identifies key features Seeks to list assumptions and unknowns
17. Roadmap pitfalls Established without engineering involvement
18. Roadmap pitfalls Assumptions presented as fact
20. Product compass Where the product headed and why List of assumptions and unknowns Essential value proposition
21. Focus scope 2
22. Traditional mindset Views scope as an external concern Doesn’t question the value of a feature Doesn’t offer ways to limit scope
23. Prototyping mindset Focuses scope on what's important Defers features that aren't vital Looks for ways to test assumptions
24. Complete product vision Minimum viable product vs
25. Scope is king Incredible impact on time and cost Best leverage for launching early Less is more
26. Focus on key, high value features, not just an arbitrary feature list because someone thought it might be useful.
27. Measure progress 3
28. Traditional mindset Views features built to spec as successful Considers user feedback another's concern Is unsure if a feature solves the problem
29. Prototyping mindset Asks how to gauge success before starting Highlights assumptions to test Validates value through user feedback
30. A reasonable outcome for any feature is that you will remove or change it significantly.
31. Progression of validation 1. Acceptance criteria 2. User feedback 3. Observing behavior 4. Engagement metrics
33. View every feature as an experiment. Each gets validated before you consider it a success.
34. Embrace Simplicity 4
35. Traditional mindset Implements the full feature Doesn’t seek minimal or alternative solutions Complicates feature with future-proofing
36. Prototyping mindset Implements bare minimum necessary Looks for minimal code alternatives Builds in small composable parts
37. – Mark Randall, Chief Strategist, VP Creativity at Adobe “Only write code when you can't think of any other way to validate your hypothesis.”
38. Overengineering Trying to predict the future, we complicate our solutions in an attempt to future-proof.
39. – Ward Cunningham “What's the simplest thing that could possibly work?”
40. You aren’t gonna need it YAGNI
41. – Ron Jeffries “Always implement things when you actually need them, never when you just foresee that you need them.” Just in time programming
43. One week rule Each self-contained part should be able to be rewritten within a week.
44. Optimize for deletion Less coupling Smaller, less complex units Reduces the cost of change
46. If it’s not absolutely necessary, defer the decision.
47. Avoid feature polishing 5
48. Feature polishing? Pixel perfect UI Honing the user experience Refactoring to the best possible code Protecting against every edge case Optimizations
49. Traditional mindset Embraces feature polishing as a given Strives to always ship the best possible code
50. Prototyping mindset Builds a ‘good enough’ version quickly Focuses on quality when key to validation Creates a solid foundation to build upon
51. Polishing a feature that gets removed or changed is waste.
52. You gain more value by validating your next feature, than polishing something that's good enough.
53. Perfect is the enemy of good enough.
54. Understand trade-offs 6
55. After validation Stick with what’s good enough Polish what you have Modify based on feedback Rewrite based on what we learned
57. For every short-cut you put in, you should have a strategy to make it right.
58. Unfinished parts It is vital that the entire team, especially the product owner, understands that we’ll need to revisit unfinished parts.
59. What can you do?
61. Scaling Agile Small, cross functional teams, called squads, that own their customer-facing product end- to-end.
62. Applying these ideas Invoke YAGNI whenever it makes sense Reduce the complexity of your solution Focus on learning and tight feedback loops
63. Thank you! Questions? Marty Haught @mghaught http://haughtcodeworks.com