Wrapping up the your product failed because you didn’t enable your users to realize value branch of the root causes of product failure, is this article on the context in which your user is using your product. If you ignore your user’s context, they won’t be able to realize the value you provide – or won’t be interested in solving those particular problems at that particular time.
Category Archives: Software development
Why Do Products Fail? – Forgetting that Users Learn
Next up in the series on the root causes of product failure – products that fail because you have ignored the user’s level of experience. The first time someone uses your product, they don’t know anything about it. Did you design your interfaces for new users? After they’ve used it for a while, they get pretty good at using it. How much do you think they like being forced to take baby steps through a guided wizard now?
Read the rest of the article …
Posted in Interaction design, Interface Design, Ishikawa Diagram, Kano Analysis, Prioritization, Product Management, Requirements, Requirements Models, ROI, Software development, UX
Tagged Agile, elastic users, expert users, learning curves, novice users, personas, prodmgmt, user personas
67 Comments
Why Do Products Fail? – Incomplete Solutions
This article continues the series exploring the root causes of product failure. Even when you target the right users, and identify which of their problems are important to solve, you may still fail to solve the problems sufficiently.
20/20 Vision – Innovation Game in Action
Having an outside-in bias as a product manager is important – you need to understand how your customers (or your customer’s customers) would value capabilities you might build into your product. When running a workshop to collect that information, playing some “serious games” is a great way to get more and better information. We ran a few 20/20 Vision games last week, to great effect.
Posted in Interaction design, Interviews, Prioritization, Product Management, Requirements, Requirements gathering, Uncategorized, UX
Tagged 20/20 vision, agile product management, customer centric, customer experience mapping, customer journey mapping, innovation games, market driven, Prioritization, Product Management
19 Comments
Specializing Generalist
The ideal agile team is made up of specializing generalists – but what does that really mean? The goal isn’t to prevent functional silos of expertise, it is to allow people to cover for each other.
Read the rest of the article …
Posted in Agile, People management, Process Improvement, Software development
Tagged Agile, specializing generalist, team
41 Comments
Agile Estimation, Prediction, and Commitment
Your boss wants a commitment. You want to offer a prediction. Agile, you say, only allows you to estimate and predict – not to commit. ”Horse-hockey!” your boss exclaims, “I want one throat to choke, and it will be yours if you don’t make a commitment and meet it.” There’s a way to keep yourself off the corporate gallows – estimate, predict, and commit – using agile principles.
This is an article about agile product management and release planning.
Posted in Agile, Business Analysis, Prioritization, Process Improvement, Product Management, Project Management, Requirements, ROI, Software development, User Stories
Tagged agile estimation, agile prediction, agile release planning, cone of uncertainty, project planning, release planning
104 Comments
Agile Documentation
Agile values working software over comprehensive documentation – it is 1/4th of the original manifesto. That doesn’t mean don’t document! It means don’t document more than you need to document. Documentation does have value, but the practice of documenting got excessive – that’s why a reaction to the bad stuff earned a spot as one of the pillars of agile. How do you avoid over-reacting when changing a culture of over-documentation?
Good Stuff on Agile and UXD
Best practices for user experience design and agile. I don’t have the brainpower at the moment, or the experience and eloquence in general, to say it better than these guys. So this week, I’m phoning it in, and deferring to these folks to say it far better than I can.
Read the rest of the article …
A Prototype is Worth a Thousand Lines of Code
A picture is worth a thousand words. A prototype is worth a thousand lines of code. Two key elements of product management – and of agile development are elicitation and feedback. Low fidelity artifacts can significantly improve both. Polished, codified prototypes can create problems that prevent you from getting the benefits of communication.
Posted in Agile, Business Analysis, Business Rules, Interaction design, Interface Design, Product Management, Requirements, Requirements gathering, Software development, Uncategorized, UX
Tagged agile interaction, Communication, process prototyping, prototypes, prototyping, uml as prototype
28 Comments
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.
Latest Articles
Comments on all Articles
