At the topic of agile, lean, DevOps, and all that “digital transformation” stuff is a renewed focus on customers and figuring out what they want to give you money for, then making the product as good as possible for them:
VGZ decided to focus its efforts on improving the customer experience. The starting point was not a traditional customer segmentation — the leadership instead decided to focus on understanding and improving customer journeys, specifically the frequency of customer interactions and the impact on the life of customers.
Very “jobs to be done.”
Original source: Agile processes can transform companies from unexpected places: The VGZ success story
‘Here’s how to make the argument to a stakeholder on your team that really wants to see that end-to-end vision: If the idea is to get value out to customers as fast as possible, does it make sense to explore every customer touch point? The time spent doing that intensive research could’ve been spent building and delivering an MVP for customers and get them excited about. Repeating this cycle gets the team to “learn by doing” and is actually a faster way to truly understand the customer’s end-to-end journey. It’s also a lot more engaging work than research and makes the team stronger.’
Original source: Why Starting With End-to-End Customer Journeys Isn’t Good For The Customer
Creating the process itself is agile. Also, a chart with activities and a suggested timeline.
Original source: Taking Agile Transformations Beyond the Tipping Point
For internal products, the “customer” is the enterprise, usually their strategy and execution, aka, “grind and stack.” Staff are, often sadly, meatware enablers in the value stream just like any technology. Optimize the VSM, make more paper.
Original source: Internal Product Management: the Good, the Bad and the Ugly — Black Swan Farming
Just getting some basic design-think in there would probably solve most problems: ‘Nine in 10 respondents believe their agency “needs to spend more time on improving the usability of technology, as opposed to the development of the technology itself.”’
Original source: Three imperatives for federal agencies to capitalize on digital transformation
‘That discussion starts with a very concise and useful distinction between project management (the world the government knows) and product management (the world it doesn’t). Project management, they write, is “focused on managing to a plan” — such as managing schedule, budget, risk, policy compliance and then reporting status to stakeholders. “Success for a project manager is delivering a defined scope of work on-time and on-budget,” Johnston and O’Connor note. Product management, meanwhile, “is focused on delivering a product a user wants or needs.” Success for a product manager “is delivering a product that users love — and use to complete tasks (or in the private sector — a product customers will pay for).”’
Original source: Project management vs. product management
“It seems to me that in our meetings so far we’ve seen many many helper-types — supporters, planners, document writers, and so forth,” he went on. “But it’s a very rare event when we have a meeting with what I would consider to be programmers. One of my most fun questions is to sit in a room with 20 executives, shall we say, and say how many programmers and it turns out there’ll be two — of which one is being transferred for some stupid reason to some other base.”
Original source: Defense Innovation Board unveils ‘Ten Commandments of Software’
“The metrics can be broken down into four broad categories — deployment rate metrics, response rate metrics, code quality metrics, and program management, assessment, and estimation metrics. The DIB also provides general timeframes for what a “good” score looks like for each metric.”
Original source: Defense Innovation Board proposes new metrics for assessing DOD software development