Tag Archives: incremental development

Know Your Competition – Comparing Products Part 6

You start with a point of view about what makes a minimum viable product.  When your product launches, it is your customer’s point of view that matters.  You must understand which problems your customers care about solving, and what solutions are available to your customers today.  You need to understand your competition to make informed decisions about your product.  This is the latest in a series on comparing products – jump back to the beginning of the series to catch up, we’ll wait.
Read the rest of the article …

Important Customers – Comparing Products Part 5

A good product is one that solves valuable market problems.  To be successful in the market, a product needs to solve the problems that the right customers are willing to pay to solve.  To know if those customers are willing to pay, you need to understand how they perceive your product relative to alternative solutions.  If you’re new to the series, head back to the intro article on comparing products, and catch up with this article, where we look at pulling together the information about which customers are important.
Read the rest of the article …

Important Problems – Comparing Products Part 4

If you understand the important market problems, you can make a good product.  If you understand how important each problem is, for each group of customers, you can make a great product.  If you’re new to this series, go back and start at the first article, we’ll wait for you right here.

Read the rest of the article …

Market Problems – Comparing Products Part 3

Comparing products without an understanding of the important market problems by which to compare the products is a waste of time.  This is the third in a series on comparing products - jump back to the introduction if you haven’t already read the previous articles.  Go ahead, we’ll wait, then come back.

Read the rest of the article …

Cadence Versus Risk

I’ve been thinking about the software development process.  Big, upfront, design and requirements.  User research and analysis.  Market insights, gained on exploration or over time.  Release cadence – how quickly you get, and incorporate, feedback from your customers about your product.  How quickly you react to your competitors’ reactions to your actions.

Read the rest of the article …

Use Cases for Iterative Development

Almost everything I’ve read about use cases focuses on describing what needs to be added to your product.  Agile development says “get it working first, make it better second.”  That means changing the way the software enables a user to do something they can already do.  How do you manage requirements for incremental improvement?

Read the rest of the article …

Flashback: A Year Ago This Week on Tyner Blain [2006-04-21]

A look back at the best from a year ago.

Read the rest of the article …

Agile Development Methodology Comparison

Agile project management has entered the mainstream – incremental delivery is now common and (should be) expected for any new software development project. Which agile development methodology should you use on your project? There are at more than ten to choose from. What makes them different? The risks that they try to address.

Code Debt: Neither A Borrower…

Code Debt is the debt we incur when we write sloppy code. We might do this to rush something out the door, with the plan to refactor later. Agile methodologies focus on delivering functionality quickly. They also invoke a mantra of refactoring – “make it better next release.” This can create pressure to “get it done” that overwhelms the objective of “get it done right.” Taking on code debt like this is about as smart as using one credit card to pay off another one.

Gartner research on Agile Requirements Definition and Management (RDM)

Gartner has a research report available for $95, titled Agile Requirements Definition and Management Will Benefit Application Development (report #G00126310 Apr 2005). The report is 7 pages long and makes an interesting read. Gartner makes a set of predictions for 2009 about requirements definition and management (RDM) systems, and the software created with RDM tools. Gartner misattributes several benefits of good process to RDM tools. We give them a 3.5/7 for their analysis – check out the details here.