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
Building is never a straight line You might think that Mario 64 was built with tickets and sprints, but, according to interviews, there was no master plan, only the principles that the game should feel good and be fun. They started with just Mario in a small room, and tuned his animations and physics until he felt nice and responsive. After that, the levels were also created as they went, with the designers, developers, and director going back and forth using sketches and prototypes. Building like this is never a straight line. Ideas and code get left on the cutting room floor because part of innovation is questioning whether what you made should exist. The process is cyclical and iterative, looking something like this. Pirijan Ketheswaran, Why Software is Slow and Shitty pketh.org Follow the funEngineers who love their work agileiteration