What is this about?
Introducing practical approaches for applying lean principals and agile development methods is one of the key goals of ‘Staring a Tech Business’.
After I used what became the “Four D’s” diagram (2nd below) in a couple of posts (“Tinkering..” and “MVP”), I got quite a few questions about it. Most of them were from folks on the “business side”- project managers, product managers, managers and entrepreneurs. Generally speaking, they were looking for ways to more effectively apply newly popular ‘lean’ principals to their company’s overall continuous improvement. In many cases, their engineering organizations were already practicing agile, but the interface to the rest of the organization was small and didn’t have a lot of throughput.
The diagram below summarizes what I heard and understood from the reader questions:
There’s a big void between the desire to apply lean principals and what goes on in a lot of development engineering programs. Engineering’s fault? No- no more than anyone else is, at least. Most engineering organizations I know (including my own) are under more and more pressure to increase output. If the inputs coming at them aren’t well formulated and integrated into a tenable process, inclusion of those inputs is going to be slow and difficult.
“The Four D’s”, described in the diagram to the right, are an attempt to provide an integrated perspective on linkages between lean principals and agile development. This is certainly not the only way at looking at how to apply lean principals or agile. What it should do for you is provide a lightweight framework for thinking about the focal points and transitions in an organization that’s effectively practicing continuous improvement.
The balance of this post describes the “Four D’s” and how to apply them.
The Minimum Viable Product (MVP)
The basic idea with an MVP is that you’ve pared your product down to the absolute minimum set of features you need to launch to your early market. 
Why is this so important? The underlying assumption is that in an environment of uncertainty, which is what you have with any new product, you just can’t understand the whole product/market fit in advance. So, the idea goes, get it in front of your target users sooner vs. later to start your user-validated learning ASAP.
Since this post is about continuous improvement, I’ve assumed you’re already somewhere post-MVP delivery in your customer development. That’s why the MVP shows up as an input to the Discover circle in the preceding diagram. That said, here are a few quick notes to help you sniff out how things are going with your MVP if that’s where you are in your customer development.
Four tell tale signs you have a healthy MVP creation process:
- Your Key Startup Assumptions are Explicit
One key element of applying lean principals to a startup (popularized in Eric Reis’ aptly named book ‘The Lean Startup’) is that you should lay out all the assumptions that have to be true for your startup to succeed. Then you should decide which ones can be accepted as true at face value. Then determine which ones need to be proven and design the quickest, cheapest possible experiments you can think of to prove them. - Your Assumptions are Prioritized
Time and resources are scare in a startup. You should prioritize your unproven/non-validated assumptions to make the best use of your resources- put important ones that require few resources and time at the top and one that are less important and require more resources at the bottom. - The MVP is Well Delineated
The stories (that describe product functions) are clearly designated as being essential or non-essential for the MVP. Every time a new feature comes up for discussion, it goes in one of those buckets. - Development is Focused on the MVP
Your development organization is 100% focused on getting the MVP out the door to start your validated learning. While you should certainly keep talking about new ideas, prioritization of your post-MVP development should be driven by validated learning from your customers/users.
Four tell tale signs you do not have a healthy MVP creation process:
- Few or No Shared Assumptions
Among the key players, there isn’t yet a set of shared assumptions about what will make the business successful. If you’re still in the early stages of customer discovery and business formation, this is a healthy debate. If you’re in the process of implementing an MVP, it’s trouble. You should drive to a shared set of assumptions as soon as possible. Remember, the idea is to lay out the assumptions you need to validate to make the business work and then prove or disprove them. It’s perfectly OK to have different opinions about which assumptions are likely or unlikely to prove out as long as everyone’s working towards validating them in an objective way. - The Process is Organized around a Traditional Organization Chart
A startup is not the same thing as an established business. A startup needs a small, flat team that is out learning about the customer and can implement a very tight discover-design-develop-deploy loop. Traditional organizational structures (marketing, sales, product management, engineering, operations) are more scalable but too cumbersome (not to mention expensive) for a company that’s learning what to build and how to operate. - No Clear Success Criteria or Metrics
How will you validate your key company-making assumptions? What’s the definition of success? When will you know whether the plan is working or whether you should scrap it and pivot to a new plan? If you’re not sure of this, you should backtrack and work to it as soon as possible. - Engineering is Behind the Curtain
If no one is hearing from engineering while they’re developing the MVP, that’s normally a distress signal. If you’re very early in the product development process, it’s unusual that there are no questions for the folks out talking to customers. If the customer discovery and engineering teams are one in the same, obviously, that’s fine.
Here are a few general resources that I think will help in this area:
- These Tutorials
- These Resources
- Chapters 1 and 2 of ‘Starting a Tech Business’
- For something quick, here’s a recent post I did (on the Leonid site) around MVP’s
Discover
What you’re looking to do here is learn about the customer in their natural environment. Have you seen shows on Animal Planet where they go out and observe wildlife doing its thing? This isn’t that different. It’s not the same thing as selling- you’re learning about what’s going to naturally resonate with a particular type of user/company, not testing your pitch. Watch what your customer does with your product when they get their hands on it. Instruct them as little as possible- remember, you’re using these customers as a sample to understand how a much larger population of users will react to what you have.
Four tell tale signs you have a healthy Discovery process:
- “Product Savvy” Staff are Logging Observations with Customers
“Product savvy” doesn’t necessarily mean “technical” but it does mean the person in question understands your product well and at the same time can peel back customer feedback and questions beyond the obvious to discover what’s really at the heart of the user’s desire. (Pitch: Reading ‘Starting a Tech Business’ is a great way to get there!). - Those Same Staff are Packaging Their Observations
These same staff should understand the basics of how to package their observations- describe a user, tell an agile user story, and provide vivid user-driven descriptions. On the high end, they have experience with usability testing. - You have Broad-Based Participation in Discovery
This is a core aspect of lean principals, all the way back to the Japanese concept of Kaizen. Training employees how to look beyond problems towards opportunities for improvement is an inexpensive way to improve performance. - You Have a Prioritized Hit List of What You Want to Learn
While you want to constantly be on the lookout for things you can learn about customers, you should also have a pretty specific list of things you validate that is tied to a) validating/invalidating what you just released and b) validating/invalidating what you’re planning in the next release.
Four tell tale signs you do not have a healthy Discovery process:
- Development is Driven by What Breaks
You’re scheduling your development priorities around things that are broken or literal reactions to customer complaints (there’s nothing wrong with responding to customer complaints but there is something wrong with having individual customers design your product). - You Spend Time Pitching Customers and Cramming the Product into a Fit
Instead of observing customers and seeing what they want to do, you’re constantly pitching them the product and trying to cram what they want to do into the existing capabilities of the product. - You’re Quoting what Customers Say
Your customer discovery teams are spending time documenting exactly what customers said instead of analyzing what their statements really meant. Remember, it’s not your customers’ job to design your product and they’re not trained to think systematically about what they really want the product to do. - Your Backlog is Not Driven by Discovery
Your feature implementation priorities are being driven by someone who is not working hand in glove with the customer-facing teams.
Here are a few resources that I think will help in this area:
- The Talks on Design Thinking
- The Resource Page on Ideation
- Chapters 1 and 2 of ‘Starting a Tech Business’ for understanding the process of discovery
- Chapter 3 for understanding how to think about the components of your product and describe updates to your development team
Design
Design thinking is a big organizational fad, and hopefully one that’s here to stay. There’s a lot you can do to learn about design, most of it not things you get in a typical undergraduate program (outside product design itself). In a single sentence, design thinking has to do with increasing your empathy towards users’ problems and creativity in solving them. In practical terms, tuning your ability to learn about users, write up user personas, and deliver user stories are some of the more immediately useful skills you can develop. The most fundamental idea you can take to heart is that you’re designing a product around a user not trying to program a user around a product.
Four tell tale signs you have a healthy Design process:
- Everyone’s Encouraged to Think Like a Designer
This means (at a minimum) that everyone’s trained to put themselves in the shoes of a user and articulate creative solutions to their problems. For a terrific and inspiring explanation, see Donald Norman’s article ‘My Dream: The Rise of the Small’. - Product Design Involves Direct Interaction Between Implementers and Customer-Facing Staff
What you ideally want is a safe, open forum between the folks that are out learning about the customer and the folks that know about the product implementation. The further away you move from this, the more fidelity you lose. Also, more is not more- I find meetings of this type with over five people are thieves of time where not much is accomplished. - Engineering Development Constantly Bugs Customer-Facing Colleagues
If you’re in the early stages of your product development, your implementers should probably be encountering questions where they want to hear from the voice of the customer. This isn’t universally true but if you’re consistently missing the mark on usability and customer interface, consider enhancing the ‘product owner’ interactions, assuming you’re using agile. - Multiple Solutions to Substantial Problems are Considered
More is not more- if you know what to do, do it. But if your teams are putting together multiple alternatives and discussing them with their colleagues and the customer-facing teams, that’s a good sign you have a robust design process.
Four tell tale signs you do not have a healthy Design process:
- Design is an Engineering Thing
If design is just an engineering thing and, in agile terms, the product owner role is weak or nonexistent, you’ll have a highly serialized process (at best) for learning what product implementations are working for you. - Decision by Committee
You want interdisciplinary participation and broad-based input, but that doesn’t mean design-by-committee. That rarely produces good product. Your best bet in agile terms is to have someone in the product owner role that’s entrusted to make final design decisions. - You have “Requirements” Instead of “Stories”
Requirements obscure motivation and make people behave like legislators. User personas and stories provide purpose-driven inputs to the design process. - Lots of Discussions about the Technology
Your discussions should be about what the user wants to do vs. how the technology behaves. It’s not that hard to make the technology do the right thing in most cases.
Here are a few resources that I think will help in this area:
- The Talks on Design Thinking
- The Resource Page on Ideation
- Chapter 3 of ‘Starting a Tech Business’ around product design
- Template for linking customer discovery to agile user stories (same as previous section)
- Donald Norman’s seminal book on product design, ‘The Design of Everyday Things’
Develop
This is the area where agile started and has been most successful. I have little to add in this context.
Four tell tale signs you have a healthy Development process:
- Healthy Overlap Between Phases
Development should have a healthy overlap with design and delivery. That means the implementers are heavily involved in reviewing design decisions made with user personas and stories in mind. - Healthy Correspondence with Product Owner
The product owner is responsible for answering questions about the user during implementation. Healthy correspondence with this implementation generally indicates healthy consideration of alternatives and how they’ll affect the user. - Questions Arise on Delivery
Do the implementers raise questions on how new features will be delivered? This might be the links between implementation and infrastructure (upgrades, operation, management) or it could be user help and discovery. - Output Relatively Predictable
This is one of the hardest things a development manager has to do and it’s especially difficult in the early phases of a new product and/or team. That said, if you’re moving towards greater predictability, that’s a good sign.
Four tell tale signs you do not have a healthy Development process underway:
- Long Cycles
In a dynamic environment, long cycles are tough because they protract the feedback loop, making it hard to know if you’re on the right track. - Development to Specification
If there’s a lot of discussion about whether something matched the specification versus made sense for the market, you know you need to change up your processes. - Development is Closeted
If no one that corresponds with the customer is involved in development, that’s a bad sign. - Output Unpredictable
Predicting output is hard, but it should become increasingly visible the longer you work on the same product with the same team.
Here are a few resources that I think will help in this area:
- The Talks on Product Development & Agile
- The Resource Page on Development & Agile
- Chapters 5 and 6 of ‘Starting a Tech Business’ around product design
- Greg Cohen’s book on agile for project managers, ‘Agile Excellence for Product Managers’
Deliver
This one is last but not least- many excellent product flounder because of poor delivery. Why? I think it has to do with the fact that delivering a great product is exciting but attending to all the details around delivering it to a customer is perceived as boring. In a healthy organization, delivery is highly process (checklist) driven and tightly linked to the output from development and planned discovery from the customer.
Four tell tale signs you have a healthy Delivery process:
- Well Delineated Transition from Development to Delivery
Are all the things you need to do to make sure you can upgrade to the new release and enable customers on it well described? Implemented in a systematic way? - Strong Linkage to Discovery
Inevitably, customer about new features will arise during development that just can’t be answered without direct interface to customers. Are the seeds of discovery planted during delivery? - Changes are Explained (better: Sold) to Users
Will your customers be as psyched as you are about the new features? Have you given them a reason to be? You need them interested before you can discover whether they like the new stuff. - Delivery is Process Driven
Is the delivery process itself highly process driven? This means having clear, documented processes in place with distinct inputs and output. Each should have a clear owner as well.
Four tell tale signs you do not have a healthy Delivery process:
- New Releases Just Arrive
Does your operations team struggle with new releases? Do customers? These are signs the linkage from development needs work. - First News on Release is in Ticketing System
Is the first data you have on a new release from the ticketing system? If so, there may not only be an issue with the linkage with development but discovery as well. You may need to review your customer development infrastructure. - Heavy Trouble Tickets
Do you receive an uptick in trouble tickets after a new release? Any product change will drive an uptick in your support volume but if you’re seeing large spikes that’s not a good sign. - Little Process
When things go sideways, do you have a process to review as a starting point to figure out what went wrong? If not, more explicit process development is something you may want to consider.
Here are a few resources that I think will help in this area:
- Chapters 6 and 7 of ‘Starting a Tech Business’ around delivery and process, respectively
- The process template from Chapter 7 (coming soon)
In Closing
If this seems like a lot of new material that’s either new or you want to do but haven’t yet, my advice is:
- Prioritize: Don’t try to do too many new things at once. Decide what’s most important and bite off a soluble piece.
- Delineate: Figure out what improvements you’d like to see as a result of the change and what criteria you’ll put in place to make sure it’s working.
- See how it goes: Give the change a reasonable period to succeed or fail and then assess.
Feedback? Ideas? Stories? Please post here or drop me a line at acowan@alexandercowan.com.
