惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
V2EX
Cisco Talos Blog
Cisco Talos Blog
MongoDB | Blog
MongoDB | Blog
IT之家
IT之家
N
News and Events Feed by Topic
博客园 - 叶小钗
Help Net Security
Help Net Security
美团技术团队
Attack and Defense Labs
Attack and Defense Labs
雷峰网
雷峰网
S
Security @ Cisco Blogs
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
WordPress大学
WordPress大学
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
AI
AI
Hacker News: Ask HN
Hacker News: Ask HN
T
The Blog of Author Tim Ferriss
Security Latest
Security Latest
Last Week in AI
Last Week in AI
S
Secure Thoughts
Simon Willison's Weblog
Simon Willison's Weblog
TaoSecurity Blog
TaoSecurity Blog
N
News and Events Feed by Topic
A
Arctic Wolf
Y
Y Combinator Blog
MyScale Blog
MyScale Blog
Cyberwarzone
Cyberwarzone
酷 壳 – CoolShell
酷 壳 – CoolShell
S
SegmentFault 最新的问题
罗磊的独立博客
Vercel News
Vercel News
D
DataBreaches.Net
博客园 - 聂微东
P
Palo Alto Networks Blog
N
News | PayPal Newsroom
GbyAI
GbyAI
B
Blog
A
About on SuperTechFans
PCI Perspectives
PCI Perspectives
S
Schneier on Security
Apple Machine Learning Research
Apple Machine Learning Research
I
InfoQ
The GitHub Blog
The GitHub Blog
P
Privacy International News Feed
Blog — PlanetScale
Blog — PlanetScale
博客园_首页
T
The Exploit Database - CXSecurity.com
V
Vulnerabilities – Threatpost
aimingoo的专栏
aimingoo的专栏
Google DeepMind News
Google DeepMind News

AWS Executive in Residence Blog

You CAN Manage, Forecast, and Evaluate AI Costs | Amazon Web Services Experience, Exploration, Execution: The Three Channels Reshaping Retail | Amazon Web Services You Wanted to Become AI-Native, and All You Got Was a Lousy Foundation | Amazon Web Services AI, Technical Debt, and the Path to Real Fluency | Amazon Web Services True Data-Centricity | Amazon Web Services Agentic AI: Bridging the Widening Gap Between Ambition and Execution | Amazon Web Services Moving from Efficiency to Growth: How Junior Talent Outpaces Tenure with AI | Amazon Web Services Most Organizations Can’t Use AI Agents Across Teams—Here’s Why | Amazon Web Services AI and Digital Transformation | Amazon Web Services Your AI Coding Assistants Will Overwhelm Your Delivery Pipeline: Here’s How to Prepare | Amazon Web Services AI Increased Productivity? Consider Hiring More Developers! | Amazon Web Services The New Unit of Software Delivery: The Workflow | Amazon Web Services From Business Logic to Working Code: How Kiro Changes Who Can Build | Amazon Web Services Measuring the Impact of AI Assistants on Software Development | Amazon Web Services From Tools to Teammates: CTO’s Guide to Evolving Architecture for Agentic AI | Amazon Web Services Leveraging AI and Cloud for Supply Chain Resilience | Amazon Web Services Why 2025 is the Inflection Point for AWS Cloud Migration | Amazon Web Services From Automation to Agency: Leading in the Era of Agentic AI | Amazon Web Services Proven Practices for Succeeding with a Multicloud Strategy | Amazon Web Services Quantifying the Impact of Developer Experience: Amazon’s 15.9% Breakthrough | Amazon Web Services Responsible AI: From Principles to Production | Amazon Web Services Don’t Blame Regulators: How Software Excellence Satisfies Compliance | Amazon Web Services From Possibility to Practice: Reinventing the Enterprise from the Inside | Amazon Web Services
Break Through Barriers: Accelerate Innovation in Traditional Organizations | Amazon Web Services
2025-05-20 · via AWS Executive in Residence Blog

AWS Executive in Residence Blog

Driving successful innovation quickly is a major challenge for many organizations, even in the generative AI era. Only 21% of organizations achieve their innovation goals.1 The typical concept-to-launch journey still takes about 22 months, and 82% of engineers say they’re “constantly looking” for ways to speed it up.2 Slow go-to-market timelines mean missed opportunities and reduced competitiveness.

Many traditional organizations, inspired by successful startups, adopt methodologies such as the Lean Startup, Agile, and design thinking in hopes of achieving similar results. These frameworks focus on customer-centric problem-solving, iterative experimentation, and rapid learning. Startups thrive using these frameworks, but traditional businesses often struggle to implement them effectively.

The issue lies in execution. Deeply ingrained cultural and structural barriers—fear-based decision systems, misaligned incentives, perfectionism, and outdated processes—prevent these methodologies from taking root. These implementation barriers create operational challenges and pose strategic risks. They affect how well a company competes and its ability to respond to the market.

In this post I discuss how a structured innovation process, like a four-week sprint, can help. I also discuss the potential challenges that traditional organizations may face when implementing such processes and offer advice on how to overcome them.

Week 0: Laser-Focused Team Setup

Before you start an innovation sprint, assemble a priority-protected pod—a team insulated from the daily whirlwind of organizational demands. The simplest pod includes a single-threaded leader (STL) and three to five core members (spanning business, technical, and design roles) who commit more than 50% of their time to the sprint. An STL is fully dedicated to solving one business problem, free from competing responsibilities, so they can be focused and accountable. You should also have a leader outside the pod provide executive air cover to protect the team from external distractions.

Traditional organizations struggle when departments “borrow back” resources or when managers resist goals that don’t support their own key performance indicators (KPIs). To fix this, leaders should create a pact to identify and support nonnegotiable sprint goals. Establish a Do Not Disturb protocol so teams can work uninterrupted. Track alignment through daily five-minute check-ins where members report sprint and departmental tasks. If something is off, you can correct course.

Week 1: Customer Discovery Through Ethnographic Research

During Week 1, observe users and look for their pain points. For example, a health app team shadowing patients might discover they don’t want complex dashboards but rather simple, actionable insights like the answer to “What can I do today to improve my health?”—evidence impossible to gather from assumptions alone.

Organizations typically revert to traditional research methods, such as focus groups and surveys, to ask users, “What features do you want?” This yields superficial feedback, like “More data” or “Better dashboards,” and misses deeper user frustrations. Decision-makers compound this problem by assuming they already know what customers want based on past experience.

Breaking this cycle means leaving old habits behind. Teams can use shadowing and journey mapping to immerse themselves in the user’s world. By asking open-ended exploratory questions, teams can uncover the user’s genuine needs rather than confirm existing assumptions. This ensures your innovation journey begins with a clear understanding of the problem you need to solve.

Week 2: Rapid Prototyping of a Low-Fidelity MVP

Week 2 focuses on creating quick prototypes that validate core assumptions. For a health app, this could mean creating a simple interface with one actionable insight, such as personalized activity goals from wearable data, to validate patient engagement.

The principle is simple: build just enough to learn. But perfectionism dominates traditional organizations. In risk-averse cultures, employees fear consequences from releasing work that others judge as incomplete.

To overcome this, leaders must create an environment where early experimentation is valued over exhaustive planning. Your team needs psychological safety to make Week 2 work. You should reward them for taking calculated risks.

Some practical ideas include:

  • Time-boxing prototypes to 24 hours. Ugly-first-draft sprints force teams to focus on one critical assumption per day.
  • Create failure resumes, where teams preemptively list prototype flaws and document anticipated failures as learning opportunities.
  • Allocate a scrap budget (e.g., allocate 15% of sprint costs for failed tests).

Week 3: Measurement and Testing with a Small Group of Users

Week 3 focuses on gathering actionable data through small-scale testing. For a health app, KPIs might include user engagement rates, user feedback on making better health decisions, and time saved interpreting health insights. Traditional organizations often stumble here because of bureaucracy and unclear metrics.

Approval systems slow down launch timelines as projects are subjected to multiple sign-offs, even for pilot tests. And teams frequently track vanity metrics, like feature count or download numbers, that fail to reflect real user value. Without meaningful KPIs tied to customer outcomes, organizations can’t validate their solutions.

Leaders should counteract this by authorizing frontline teams to run small-scale tests and leaving the executive committee approvals until after the innovation sprint. Use clear, actionable metrics, tied directly to user needs, so you deliver reliable insights to inform the next steps.

You might track the number of shadow metrics (unofficial and often competing KPIs) that departments prioritize over official KPIs. A shadow metrics tracker exposes how legacy incentives and risk aversion sabotage innovation sprints. It measures the gap between what teams say they optimize for (e.g., customer outcomes) and what they actually resource (e.g., system uptime, feature counts). Leaders should then use the right innovation metrics to validate solutions and adjust incentive systems to encourage teams to focus on the right outcomes.

Week 4: Analyze the Results, Learn, and Pivot

In Week 4 teams analyze data and decide whether to refine, pivot, or scale the solution. For startups, this is a natural cycle of iteration based on what works. But for traditional businesses, the weight of failure often clouds decision-making. Teams can resist admitting when an idea isn’t working, fearing blame or career repercussions. As a result, they double down on flawed approaches instead of pivoting and addressing what the data says. This reluctance leads to wasted resources and missed opportunities.

To succeed in Week 4, organizations need to normalize failure and pivoting as part of the learning process. Leaders must set the tone by celebrating insights gained from pivots and reframing failure as a stepping stone to eventual success. One idea is to track assumption kill rate (hypotheses disproven) and pivot speed (days saved by abandoning dead ends). To destigmatize missteps and ensure teams learn from failures, I recommend applying a Correction of Error (COE) process, an AWS mechanism for documenting and addressing issues (COE).3

Breaking Through the Barriers

Organizations that succeed today won’t win because they have the most elegant innovation methodologies. They’ll win because they have leaders who dismantle the structural and psychological barriers that stop innovation. This is about more than operational efficiency; it’s about strategic relevance and survival. Every quarter spent struggling with perfectionism, misalignment, or fear-based decision-making allows competitors to pull ahead.

Start small. Implement one or two of these strategies in your next sprint. Get the team familiar with them, then expand to adapt all strategies. Recognize that meaningful change requires sustained leadership attention. The innovation velocity you enable today will become your competitive advantage tomorrow.

The time to act is now.

Helena

Sources

[1] $ 2.3 trillion Wasted Globally in Failed Digital Transformation Programs – Costly and Complex Business Strategies are ‘Not Necessary, Informa, 2024

[2] McKinsey: Unlocking Success In Digital Transformations, Technology Magazine, 2020

[3] Why you should develop a correction of error (COE), AWS Blog, 2022