Know What Software Features to Build Next: User Stories, Business Canvas and Market
May 17th, 2012 | Agile, Concepts, Lean Startup, Practices, Process
“Devoted to Facebook IPO”
Traditionally Project Managers make decisions for the horde of software developers what features should be attacked in the long release. Yes, this approach frees busy developers brains from the mind boggling task of thinking about the business. But developers no longer get business context – why features should be done and what is important for the business. In addition, long releases detach developers from the product market results and inhibit learning and adaptation to the customer needs.
Agile Development
Agile fixes these problems with three important practices – The Whole Team, Small Releases and User Stories. Customers and developers are one team that frequently discuss features face-to-face and create User Stories together. Important User Stories become part of the new release, others go to Backlog. The team releases features frequently and learn from customer feedback and implementation.
User Story is done when it is:
- Code Complete and Working
- Tested
- Accepted by customer
Agile is wonderful process! Developers work closely with business providing speed, accurate interpretation of requirements and intellectual contribution (surprise!) in translating business vision and needs into the concrete software system.
The Customer accepts the User Stories at the end of frequent iterations, provides feedback and change future User Stories based on experience with this real working system. In short, the customer steers the direction of the project instead of being a hostage of the unruly slow development machine.
However, one big problem remains – everything depends on the customer’s ability to get brilliant ideas, correctly read the market and envision what set of features will succeed. Unfortunately, it is almost impossible to get right. Business geniuses (except Steve Jobs), smart analysts or even consumers themselves cannot reliably predict how people would react, what they really need and will like next. And developers can contribute more to the market discovery and quality of business decisions.
Market-oriented Development
Lean startup movement, Facebook and Toyota have some interesting ideas that can be applied to the development process and improve chances of software market success.
Hackers try to build the best services over the long term by quickly releasing and learning from smaller iterations rather than trying to get everything right all at once. To support this, we have built a testing framework that at any given time can try out thousands of versions of Facebook. We have the words “Done is better than perfect” painted on our walls to remind ourselves to always keep shipping.
Hacking is also an inherently hands-on and active discipline. Instead of debating for days whether a new idea is possible or what the best way to build something is, hackers would rather just prototype something and see what works. There’s a hacker mantra that you’ll hear a lot around Facebook offices: “Code wins arguments.”
– Mark Zuckerberg, Facebook CEO
All we are doing is looking at the time line from the moment the customer give us an order to the point when we collect the cash. And we are reducing that time line by removing the non-value-added wastes.
– Taiichi Ohno, founder of TPS
The fundamental activity of a startup is to turn ideas into products, measure how customers respond, and then learn whether to pivot or persevere. All successful startup processes should be geared to accelerate that feedback loop.
– Eric Ries, Lean Startup
Market-oriented Development has three distinctive characteristics:
- Requirements goal is to maximize learning, reduce risks and uncertainty
- Build-Measure-Learn Feature Cycle
- Delivery Mechanism – Continuous Deployment and Flow
1. Requirements – Business Model Canvas and Customer Development
Maximize learning (about what’s riskiest) per unit time. Systematically eliminate risks.
– Ash Maurya, Running Lean
Your software system carries more than just technical risks:
- product risk – do you solve right problem in right way?
- customer risk – do you know who has the problem and how approach them?
- market risk – can you build effective business and make money?
Each software system feature (reflected in User Story) has similar risks on the smaller scale. Every new feature is an attempt to improve software system and business. The process should breed successful and eliminate failing features.
Business Model Canvas is an excellent source of requirements – define areas of risks and opportunities to focus on what features should be built next.
The Business Model Canvas is a strategic management template for developing new or documenting existing business models. It is a visual chart with elements describing a firm’s value proposition, infrastructure, customers, and finances. It assists firms in aligning their activities by illustrating potential trade-offs.
Another great source of requirements is Steve Blank’s Customer Development process that helps to discover, validate and create customer’s needs.
The initial result is Minimum Viable Product (MVP) described with User Stories. Developers help to cross a bridge between business models and feasible technical implementation to form MVP.
The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
2. Build – Measure – Learn Feature Cycle
Selected User Stories are transformed into Minimum Marketable Feature (MMF) for the release.
MMF must provide significant value to the customer. We use the term “marketable” to describe this concept. However, value can be measured in many ways, such as revenue generation, cost savings, competitive differentiation, brand-name projection, and enhanced customer loyalty. Even this list is by no means exclusive, as true value can only be defined within the context of the proposed project and measured by the organization developing the software.
Use Scientific Method
Build features as experiments in proving hypothesis. An experiment is valid when you can definitely measure if hypothesis has succeeded or failed.
Follow Build-Measure-Learn Cycle
MMF Extended Lifecycle:
- Generate ideas (Theory) with Business Model Canvas and Customer Development – feature should improve business or increase learning
- Survey (before development) – what are feature chances of acceptance and success (customer interview, surveys, marketing site traps for potential users)
- Build Feature as Hypothesis avoiding expensive and long effort. Technology is not so important at this stage – inefficient or even manual solutions are ok.
- Probe (run experiment) with
- beta testing
- usability testing
- flip feature for a limited group
- A/B testing
- internal / close preview
- Measure market success (validate with users, use analytics, get feedback, do cohort analysis)
- If no clear market success (traction, positive feedback) – hypothesis is not confirmed, refine it
- Outcome: validated learning – the feature is marketable!
- Release (marketable feature) to wide audience
- Adopt and Scale – make the feature reliable part of the core product
- Monitor and Optimize – improve quality and performance of the feature
- Improve feature and continue evaluating
- Is it still good, marketable and usable?
- Does it still confirm to 80/20 rule?
- Does it escape over-complication and bloating after rounds of improvements?
- Should it be replaced with something better and new?
MMF is done when it is :
- Code complete and Working
- Tested
- Accepted by customer
- Proved to be Marketable – users want and like this feature, and it can bring money / increase value
The Market-oriented Developers should target in parallel three completely different goals:
- Traditional – design a solid system and lay stable foundation for the system expansion and usage
- Agile – build a simple optimal system that can be adapted for the future changes
- Market – create a minimum quick solution to prove viability of feature early and reduce product, customer and market risks. Be ready to radically change or scrap unsuccessful features.
Developers work with two types of features: Hypothesis and Core (proved by market). As a result two kinds of development activity streams run in parallel
- Form stable core for proven features – high quality, refactored and optimized
- Build isolated hypothetical features with options to flip or remove completely (without consequences). Lower quality and shortcuts are acceptable. The main goal is to prove the feature with minimal effort and system disturbance.
3. Delivery Mechanism – Continuous Deployment and Flow
Startups that succeed are those that manage to iterate enough times before running out of resources. Time between these iterations is fundamental.
– Ash Maurya, Running Lean
Continuous Deployment is built on continuous flow techniques that were developed at Toyota. Continuous flow has been shown to boost productivity by rearranging manufacturing processes so that products are built end to-end, one at a time, versus the more prevalent batch-and-queue approach. The goal is to eliminate waste. The biggest waste in manufacturing is created from having to transport products from one place to another. The biggest waste in software is created from waiting for software as it moves from one state to another: waiting to code, waiting to test, waiting to deploy. Reducing or eliminating these wait times leads to faster iterations, which is the key to success.
– Ash Maurya, Running Lean
The software team that practice Continuous Deployment should be disciplined, professional and focused. Developers work in advanced mode – frequently release a system woven from features on different life stages instead of rarely releasing big slumps of monolithic frozen codebase.
The Flow
Input
- Business Model Hypotheses
- Core Feature Improvements
1. Develop
- Build in small batches – less disruption, easier to swallow
- Reduce work in progress – focus on features that can be completed and released in short time (otherwise reduce feature scope)
- Eliminate waste – keep only value-added code and activities
2. Test
- QA is the part of the development process, not a separate phase
- Automated Testing and Continuous Integration are core mandatory practices
- Jidoka – no failing tests, zero defect totlerance – stop and fix if a problem arises
3. Deploy
- One click deployment and rollback
- Feature flipper system (e.g. Flickr, Facebook Gatekeeper)
- Integrated Operations and Development – both teams are part of the whole process from requirements to launch
4. Monitor
- Build a Signal System that detects, alerts and recovers software system from errors
- Genchi Genbutsu – Go and See -thoroughly and objectively understand problem before making decisions
- Remove root causes – tolerate unexpected problems only once – use Toyota 5 whys and Kaizen.
This delivery mechanism enables fast product cycles for market validation, refining product and eliminating risks.
Outcome
Three mental shifts:
- Each Feature should improve a business model or increase learning about it.
- A new feature is a Hypothesis about solution that should pass Ultimate Marketability Test to become Core.
- Create lean continuous flow to achieve just-in-time delivery.
A market-oriented team goes beyond regular development practices. Developers are not only building good software system focusing on technology, but they are improving product market chances, and become active contributors in the quest for repeatable and scalable business model.
Isn’t this kind of development the best process for any business?
Books
