I’ve spent a lot of time making agile development work in startups and it ain’t easy. Necessary but not easy. Agile has always felt natural to me - from a cultural point of view that when I read about Kent Beck and XP it was exciting to see some substance forming around this approach in contrast to more prevalent and much heavier methodologies.
I liked XP as an engineer but from the business side of things found that it was limited to encouraging good engineering practices but not much else. That’s when I learned about SCRUM - the agile methodology that adds the project management rituals that are compatible with the engineering practices of XP. Great, I figured, now I can really build cool products! Er…maybe.
Scrum is the way we run the AideRSS engineering group its what I’ve used at Mindreef and previously as well. But, over the years I’ve realized that the toughest problem - the one that matters most and was consistently the most challenging - was figuring out what the product backlog should be.
The backlog is the answer to the question: “What is the most important work we should do right now?” it presumes that you could confidently make that list, and keep it up to date as things change - or at least articulate what you’re building and for whom. Embedded in that assumption is why startups fail. How do you really make the best backlog for your company?
XP and Scrum don’t have much to say - they punt. Its by far the hardest part of the puzzle of shipping successful products and both recommend that you get a customer in the room and ask them to clarify what they want as you go. Well, that’s fine as far as it goes but when you’re a startup and you don’t have customers yet you need a way to bootstrap and that can feel awfully chaotic and wasteful. What’s worse is that as you grow you’ve probably developed some pretty bad habits as far as setting priorities and strategy: like thinking you’re a genius - just because you got funded - and that genius is what allows you to *know* what the market wants.
Product Management is the generally accepted answer to the question above and though I love the folks at Pragmatic Marketing for their excellent offerings in this area, product management isn’t all that well connected to agile development, especially in a startup.
I recently listened to the VentureHacks podcast of Steve Blank’s talks at Stanford on the topic of “Customer Development”. A blog post: “How to develop your customers the way you develop your product” links to resources that describe the idea. Wrapping the iterative nature of agile development in another outer loop called Customer Development makes a ton of sense to me. Its the first time I’ve seen an approach to the Market/Product fit problem that makes sense the same way agile makes sense to software developers. I’m looking forward to digging into this some more and applying it to how we evolve at AideRSS.
Oh, some guy called Marc Andreessen things Steve’s book is nifty too.
All I can say to this is: YES! I’m psyched you’re excited to learn more.
My interest is definitely piqued! I hope you intend on publishing more classes?
I have Steve’s book on order but in the meantime enjoy reading Eric Ries’ blog on the topic: http://startuplessonslearned.blogspot.com/
[…] Customer Development - The Missing Piece! - “I’ve spent a lot of time making agile development work in startups and it ain’t easy. Necessary but not easy.” and a response by Eric from Lesson Learned […]
Just a clarification: XP doesn’t exactly “punt” on deciding what goes on the product feature list. Rather, it intentionally avoids making those decisions for good reason. It puts those decisions where it belongs: with the business people - aka the “customer” in XP terminology. (”Developers make development decisions; business people make business decisions.”)
What this means for a starup then, since you have no customer, is that someone needs to play the role of the customer - deciding what features are most important right now, what “functionality theme” the current release will be offering the market, where to draw the line determining what set of features will make up the current release, etc.
It’s ideally best if this person is not a member of the technical team (e.g., a “product manager” is ideal for this role). But if it does have to be a member of the technical staff, then that staff member should try as hard as possible to “take off their technical hat” and “put on their business hat” when they make those decisions.
I think your are getting to why I said XP/Scrum “punt” on that part. They defer to someone else to figure out what should be built and why. The problem with defering to “the business people” is that typically they don’t have a clue what should be built either! thats when product development devolves into “He who has the compiler wins!” which is so often the case - especially in startups.
In my experience its difficult to find someone with all the tools to approach this problem - the rare super-founder, but thats doesn’t scale too well. More often it becomes a group collaboration effort but the risk there is having too many people focused on the color of the bicycle shed instead of the primary mission.
In a startup, when YOU are “the business people” what do you do?
Thanks for your comments!
[…] stories are too open ended, or your product owner doesn’t have a vision (introduce them to Customer Development!), or that you can’t keep your standups focused, or that you don’t pair enough, or that […]