Ensuring Excellence An Article by Marty Cagan www.svpg.com …in so many of the best product companies there is an additional dimension that goes beyond individual empowered product teams, and even goes beyond achieving business results. It has to do with ensuring a level of what I’ll refer to here as “excellence” although that is clearly a very ambiguous term. Over the years, this concept has been referred to by many different names, always necessarily vague, but all striving to convey the same thing: “desirability,” “aha moments,” “wow factor,” “magic experiences,” or “customer delight,” to list just a few. The concept is that an effective product that achieves results is critical, but sometimes we want to go even beyond that, to provide something special. Maybe it’s because we believe this is needed to achieve the necessary value. Maybe it’s because the company has built its brand on inspiring customers. Often this dimension shows up most clearly in product design, where functional, usable but uninspiring designs can often achieve our business results, but great design can propel us into this realm of the inspiring. Do they really need it? qualitycraftproductssoftware
The Nature of Product An Article by Marty Cagan www.svpg.com Too many product managers and product designers want to spend all their time in problem discovery, and not get their hands dirty in solution discovery – the whole nonsense of “product managers are responsible for the what and not the how.” On GreatnessOne Of Us uxproductsproblemsdesign
Product vs. Feature Teams An Article by Marty Cagan svpg.com This article is certain to upset many people. Empowered product teamsViability, usablity, feasibilityWhat went wrong? featuressoftwareagile
Silicon Valley Product Group A Website by Marty Cagan svpg.com The best companies go about building great products differently. Silicon Valley Product Group (SVPG) was created to share lessons learned and best practices about how to build innovative products customers love softwareleadership
Feature parity An Article martinfowler.com Whilst Feature Parity often sounds like a reasonable proposition, we have learnt the hard way that people greatly underestimate the effort required, and thus misjudge the choice between this and the other alternatives. For example even just defining the 'as is' scope can be a huge effort, especially for legacy systems that have become core to the business. Most legacy systems have 'bloated' over time, with many features unused by users (50% according to a 2014 Standish Group report) as new features have been added without the old ones being removed. Workarounds for past bugs and limitations have become 'must have' requirements for current business processes, with the way users work defined as much by the limitations of legacy as anything else. Rebuilding these features is not only waste it also represents a missed opportunity to build what is actually needed today. These systems were often defined 10 or 20 years ago within the constraints of previous generations of technology, it very rarely makes sense to replicate them 'as is'. softwarefeaturesrepair