I’m a huge proponent of Scrum software development. I like Scrum because it forces a specific focus on ROI, it prevents middle-managers from interfering with the development process at a moment’s notice (“this screen would look cooler if the background was green! You can stay late tonight, right?”), and it encourages a team-oriented development environment, which is more enjoyable to work in than under “one man, one function” conditions.
But Scrum’s biggest advantage over other software development methodologies is that it almost obligates a development team to adapt to user feedback. In a poll of every Product Manager or CTO / CIO on the planet, 99% would claim to be “data driven” — no one would admit to pushing out products in the hope that they perform well in the marketplace. But driving iterations based on user feedback and driving updates / patches / catch-up releases based on user feedback are two very distinct things. Scrum creates the iterate – adjust cadence that allows for user feedback in the early stages of a product’s release (or, preferably, in its beta) to influence the final product. Changes made in this cadence are fundamentally different from changes made after a full product launch; they are implemented to ensure the satisfaction of future users and not to change the minds of past users. A user scorned is not only difficult to re-engage with, but she can also serve as a very destructive brand ambassador.
Data-driven development can only be accomplished through pushing a product into the marketplace in its formative stages and iterating on it until it is ready for a public launch. There are three reasons for this:
- Marketing budgets cannot be un-spent. Once a product is launched, the initial reaction of the public to it is difficult to overturn by updates or patches. The absolute worst time to conduct user testing is after thousands, or hundreds of thousands, or millions of dollars have been spent to promote a product — at that point, winning back scorned users might cost more than simply developing a new product.
- Developers need wins to maintain motivation. Pushing a product out each week and reporting incremental improvements to the organization is more encouraging than dumping a product onto the market — after a considerable crunch period — and then revealing to the organization that the public thinks the product is less than satisfactory. Everyone loves to get good news, and iterative development cycles provide more good news than bad (and even when the news is bad, it’s only bad until the next release). Crunch periods take a tremendous toll on morale, and prolonged crunch periods can wreak havoc on a company’s reputation as a place to work. Scrum dictates that everyone works a standard, 40-hour week; the requirements adjust to the team’s progress and not the other way around.
- The effects of product changes are best measured incrementally. A shorter product iteration reduces the number of possible changes that might affect the core metrics; metrics movements after long, convoluted updates are almost impossible to disentangle. Also, focusing on one metric at a time — say, retention — is more clearly outlined than undertaking a product update that increases multiple metrics at once. Each Scrum sprint should be endeavored under the auspices of a “theme” — say, increasing retention by 5%. Themes formatted this way are clear and can be objectively determined to have been accomplished or not.
One complaint I hear about Scrum development is that it’s overly dogmatic and prescriptive and doesn’t allow for freedoms to be exercised which best utilize the talents of the team. This criticism is sensible, but I think Scrum is only as prescriptive as the team lets it be: Scrum principles can be applied in a number of settings and adapted to fit the needs of the product. At its very core, Scrum is about developing a product in stages and focusing each stage on the highest ROI features of the product that can be implemented in a fixed amount of time. As a quantitative marketer, I see the opportunity in Scrum to allow for data to be collected and used to estimate the ROI of the next sprint’s features (ie prioritizing the product backlog). And as someone who works in mobile gaming, I understand that spending a single cent on user acquisition before a product has been perfected can be disastrous.
The Scrum framework is merely a structure; it’s not inherently dictatorial. The market, however, is dictatorial — it dictates whether or not your product is a success. Resist deference to the market at your own peril.
Recent