The freemium business model—in which some users use the product for free, and others use it for a fee—can be appealing. To succeed with the freemium model, you must first acknowledge that a revenue plan is not a business plan and then decide if it makes sense for your bottom line.
Scott Sehlhorst is an agile product manager, product owner, and business analyst and architect. He helps teams achieve software product success by helping them build "the right stuff" and "build the right stuff right." Scott started Tyner Blain in 2005 to focus on helping companies translate strategy and market insights into great products and solutions. Read more at tynerblain.com/blog.
Connect with Me
All Stories by Scott Sehlhorst
All requirements are built on some sort of hypothesis. Just-in-time requirements analysis embodies the idea that you form your hypothesis as late as responsible—not as late as possible.
When first hearing about agile processes, you might think that teams using an agile process cannot provide estimates, predictions, or commitments about what they will deliver. But, you can be agile and still manage risk and commit to a subset of what you predict.
When designing software, you must look beyond simply knowing the goals of your users. It's far more useful to understand the context in which the product will be used.
Of all of the requirements a stakeholder says "must" be done, how do you know which ones "should" be done? Connecting the project vision and goals to the requirements can help your team decide.
Historically, large companies relied on waterfall methods, but many of these organizations could benefit from a little "agile mojo." Applying aspects of hypothesis-driven development to requirements writing can help cut through the bureaucracy and put your team on a leaner path.