After starting and selling (and sometimes not selling) companies for 20 years, in 2015 I started working on a pretty exciting product: the general manager of the future. Specifically, I’m working to help people like you find a smoother, more enjoyable path to creating great products.
I started with a book, then talks, then workshops, then teaching in the MBA program at UVA Darden. Darden’s where I actually started to figure it out in a meaningful way.
Honestly, it was a pretty rough start. I talked too much and tried to cover way too much material. My evaluations weren’t great. Just like design or coding or entrepreneurship, teaching is a job and doing it well is hard.
Fortunately, dogged determination and ruthless introspection work for starting companies as 
well as learning to be a good instructor. After a bunch of work on using cases to deliver on the student-centered learning Darden is known for, those evaluations went up. Now, I’m proud to be part of a strong program that helps our MBA students with awesome projects like this: Stuff Our MBA’s do at UVA Darden.
You might be wondering- Did he teach 700,000 classes at UVA? Nope- and that’s where a series of experiments with Coursera, the online learning platform, came into the picture. First with a set of courses on agile, then product management, then continuous delivery, and finally coding for designers & managers, I ramped up online with the help of the team at Darden.
The first release defied my expectations- the learners didn’t like some of the courses! Here again, determination, introspection, and iteration went a long way. After spending some time interviewing learners about what the courses were (or weren’t) doing for them and testing new approaches, we’ve passed 700,000 courses served.
I still spend a lot of time working with agile teams at startups and corporations- after all, my teaching focus at UVA is on practice. Between degree teaching, online teaching, and continuing to work with founders and corporations, I’ve noticed three big things that really make agile work for teams (or not).
1. Agile Works Best When You Lead from the Front
Want to show your team that agile’s important? That outcomes are more important than output? Rather than changing the way the rest of your team works, I’ve found that it works best to start with yourself and lead from the front by going out and finding out what really does (and doesn’t) matter to users. Help your team build half as many features twice as well, and I think you’ll find that then they have the time, energy, and confidence they need to engage with new practices.
Most software ends up in the garbage, and not because it’s buggy. Most software ends up in the garbage because no one wants it. If you think about the practice of agile as spanning these three areas of a product pipeline you see below, in my experience it’s the practice of ‘Continuous Design’ where teams usually have the most upside opportunity.
This is where the product manager, PO, or, ideally the whole team, executes purposeful design sprints to make sure they’re building something that’s better than what the user already has.
You’ll know this is working when:
- You start getting more questions about the what and why of your inputs to dev. (that means they’re thinking about the user as well as the code, which is hard but important)
- There’s less pressure on output and more focus on user outcomes
- You’re able to start new features with a smaller functional footprint and clearer ideas about how you’ll decide to build them up or scrap them
2. Everything is Testable and Testing is Everything
The big caveats with this are a) not everything is testable in the same way and b) quantitative testing always feels more credible than it should, even when that doesn’t make sense. That happens all the time, but it doesn’t have to.
If you can create new habits and focal points around testing, marrying quantitative and qualitative evidence, you can get your team engaged in the exciting question of what happens with the work you all produce together.
How? In the design world, we generally decouple problem vs. solution, and those are the two diamonds you see below.
For Finding the Right Problem, you interview subjects and ask them non-leading questions like ‘What are the top 3 hardest things about finishing an HVAC repair?’. If you have a focused view of who this user is, you should observe (test for) their answers generally converging over 5-15 interviews. If you’ve never done this, it’s like going from black & white to color.
You’ll notice there’s an item ‘Demand/Value Hypothesis’ in the middle. This is where you test for demand mostly outside the context of product usability- they’re related but not the same. This is where the famous ‘MVP’ (minimum viable product) comes into play- serving as a vehicle to assess whether users want your product proposition enough to- do something meaningful (click, sign-up, pre-pay, etc.). These experiments generally have quantitative metrics with specific fail/pass thresholds. For existing products, this works, too- the fake feature test is a common example (present a new button or signifier a few times and observe the click-through rate).
Next, you have Finding the Right Solution. This is important but teams tend to spend too much time here relative to the other areas. This is where, against a backstop of fully articulated narrative (in the form of user stories) you test usability and then instrument your more refined usability hypotheses in web analytics (Google Analytics, etc.).
Finally, you have continuous delivery. If you don’t have strong work in the earlier areas, this is nice because it makes releasing less terrible. If you do have that work it is an amazing superpower that will allow you to test and learn in small batches, further enhancing your practice of Hypothesis-Driven Development.
Hypothesis-Driven Development is a nice framework for integrating these practices and helping interdisciplinary teams understand what they have in common- pretty important when you’re trying to get designers to collaborate with, say, devops engineers.
It also helps create a culture of experimentation, one where you hold all your evidence, qual and quant, to the same standard which is that it should offer relevant answers to an important question or hypothesis.
3. Digital Literacy Matters and It’s Not that Hard
Ah, the old chestnut of ‘everyone in should know how to code’. Don’t get me wrong- I agree. It’s just that what this means and, more importantly, why it matters are widely and often destructively misunderstood.
The legacy recipe for creating product managers is to make it a career pivot for a software engineer. That’s a pretty coarse filter since there’s so much variation among that population. As the need for digitally literate managers who can lead small, interdisciplinary teams continues to grow, that has to change.
How do you create those managers? If this is you, how do you become one? You don’t need a CS degree. And that’s not because those aren’t valuable- it’s because your job isn’t to instruct or audit the coders on your team. On the other hand, my observation is that you do need an understanding of the job to be effective.
What I’ve learned is that general managers in digital need hands-on experience with going from idea to code, and current learn-to-be-a-coder vehicles are not a great fit for that. They have a lot of material that such an individual doesn’t need, and lack a lot of perspective-building opportunities they do.
Any high-functioning adult can go on Codecademy and finish a module on Javascript in a day or two. Do they now know how to code? That’s ambiguous, because with only that prep they’re probably not going to be able to build their own working prototype or understand much of what a dev team is dealing with.
Instead, regardless of how much Javascript syntax they temporarily memorize, I’d say they’re in a good place (for this purpose) when they are able to do three things–
1: Take a design and identify functional components they need to make it happen
2: Google for code components and sample code
3: Integrate those and analytically debug them until they work
I’ve found that a combination of design-first cases followed by project-based practice works great, and anyone can get through it (and have a great time!). I’ve seen it work for multiple cohorts of MBA students in my Software Development class as well as my new online course Coding for Designers, Managers, and Entrepreneurs on Coursera.
In Closing…
What do you think? Hit me up on LinkedIn or Twitter– I’d love to hear from you. Also, if you’re interested in seeing some of this in action, I’m not above mentioning my online courses–
Digital Product Management Specialization
Agile Development Specialization
and
Coding for Designers, Managers, and Entrepreneurs.
