Teague Hopkins

In the fast-paced world of business, the term “innovation” is often thrown around as a buzzword, a magic pill that can suddenly transform an organization overnight. However, the reality is far from it. True corporate innovation is not a crash diet, where immediate, drastic measures are taken to see quick results, which are often unsustainable in the long run. Instead, it is a lifestyle change—a thoughtful, deliberate process that requires patience, persistence, and a forward-thinking mindset.

The Fallacy of Quick Fixes

In our quest for rapid growth and success, it’s tempting to look for quick fixes. We’re drawn to stories of startups that skyrocket to fame and fortune overnight or products that instantly change the market landscape. On closer examination, most of these fall into the “10-year overnight success” archetype: someone toiling for years before finally hitting the lucky break, or finding the right formula after hundreds of experiments. Real, impactful innovation doesn’t happen overnight. It’s the result of long-term commitment and investment. Just like crash diets promise quick weight loss but often fail to provide long-lasting health benefits, short-term innovation strategies may offer a fleeting glimpse of success but fail to sustain growth or competitive advantage.

The Lifestyle Change of Innovation

Think of corporate innovation as a lifestyle change. It’s about embedding a culture of creativity, experimentation, and continuous improvement into the very fabric of the organization. This involves:

• Long-term Vision: Setting sights on where you want your company to be in the next ten, twenty, or even thirty years. What kind of impact do you want to have on your industry, your customers, and the world?
• Sustained Investments: Allocating resources—not just financial, but also time, talent, and attention—towards innovation projects with the understanding that the payoff may not be immediate. It’s about investing in the future, even when the ROI isn’t instantly clear.
• Culture of Experimentation: Fostering an environment where failure is not frowned upon but is seen as a stepping stone towards innovation. Encouraging teams to test, learn, and iterate, knowing that not every initiative will succeed but that each attempt brings valuable insights.
• Customer-Centric Mindset: Continuously seeking to understand and anticipate the evolving needs and preferences of your customers. Innovation is not just about coming up with new ideas but about solving real problems and addressing unmet needs in the market.
• Cross-functional Collaboration: Breaking down silos within the organization to facilitate the sharing of ideas, skills, and perspectives. Innovation thrives in a collaborative environment where different departments and disciplines come together to tackle challenges.

The Engine of Growth

When innovation is approached as a lifestyle change rather than a crash diet, it becomes a powerful engine of growth. It’s not about sporadic spurts of creativity but about building a sustainable system that continually pushes the boundaries of what’s possible. This requires patience, as the fruits of such a culture may take years, if not decades, to fully materialize. Yet, the organizations that are willing to make this commitment are the ones that truly transform industries and leave a lasting legacy.

The Commitment is Worth It

In a world obsessed with instant gratification, embracing a long-term approach to innovation can be challenging. It requires a shift in mindset, from seeking immediate results to investing in the future. But the rewards of such an approach are immense. By viewing corporate innovation as a lifestyle change, businesses can create a robust engine of growth that propels them forward for decades to come, ensuring their relevance, competitiveness, and impact in an ever-evolving world.

As companies increasingly explore the potential of artificial intelligence (AI) in their businesses, it’s important for product managers to consider the risks and benefits of incorporating AI. AI can be a powerful tool, but it’s essential to use it wisely and judiciously to avoid unintended consequences.

To guide product managers in their use of AI, there’s a simple principle that can be applied:

“Just Enough.”

This principle applies to all forms of AI, whether it’s language models like ChatGPT or other types of machine learning. In fact, this principle is analogous to the use of other powerful tools like ‘git rebase’… or a chainsaw.

All three of these tools have the potential to cause significant damage if not used with care and precision. Just as a chainsaw can quickly turn a small task into a disaster, AI can create unintended consequences that are difficult to predict and even harder to fix. It’s crucial to ask yourself if there is a simpler, safer tool that can accomplish the same task before reaching for a powerful tool like AI.

Of course, it’s important to learn and practice using powerful tools like AI, but it’s equally important to do so in a safe environment. When it comes to your core business or production code, it’s essential to use the right tool for the job. Don’t be tempted to pick up a chainsaw when a pocket knife will do.

To illustrate the principle of just enough, consider the example of a product manager working on an e-commerce website. The manager might be considering the use of AI to personalize the shopping experience for each customer. While this is a powerful use of AI, it’s important to consider whether it’s really necessary. In some cases, a simpler tool like rule-based personalization might be just as effective without the potential risks and complexities of AI.

Conclusion

Product managers should approach the use of AI with caution and consideration. By applying the principle of just enough, product managers can ensure they’re using AI wisely and judiciously, without creating unintended consequences that could harm their businesses.

If you’re here, you’ve probably worked with product roadmaps before. You may even have been responsible for owning one. This article isn’t an introduction. Instead, consider bookmarking it for a few helpful reminders to come back to when you’re starting a new roadmap, or re-evaluating an existing one.

Product strategy first, then product roadmap. The strategy informs the roadmap, not the other way around. Don’t make the mistake of jumping right in to plotting a course before setting a cardinal direction.

Product roadmaps are not built on intuition and persuasion. Product management is not about lone visionaries. In most organizations, it’s an exercise in influence without authority. Don’t write your roadmap and then try to sell it to the team. Make your roadmap a shared document of the plan that everyone on the team has committed to, because they are equal partners in developing it.

Don’t wait until the end to get executive buy-in. Similarly, while you can add folks later in the process, there are a few who should be involved from the beginning:

• the business leader (CEO, or similar role within a department of a larger company);
• the head of sales, marketing, customer service, or whoever is going to be selling this product to customers;
• the CTO, or whoever leads the team that will be building the product.

Another note about working with your CTO: Any good engineering team will have work to do that is not focused on implementing new features. This includes bug fixes, refactoring, automating deployment processes, paying down tech debt, and other capacity-building activities. Have a frank discussion with your CTO about what kind of development capacity you can expect to be available for new features. Express this as a fraction of overall development time. This will help you better align your plan with actual capacity instead of an imagined ideal capacity.

Sequence, then schedule. Order features by priority before you start to schedule them to quarters or months. Not only does this help you avoid building features in the wrong order (who cares about password reset when you can’t create an account?), it also makes scheduling easier, because you can combine your sequence and user story points with dev capacity to generate an estimated schedule.

Begin discussions with a strawman. Make a first draft that you expect to be wrong, and be clear with the people you’re sharing it with that it is probably wrong. Humility is your friend. Use that artifact to collect useful input from everyone involved. It’s a lot easier to react to a concrete plan, even if it’s absurd, than to pull useful insights out of thin air.

Once you have the final draft, make sure to check with the wider team (legal, compliance, HR) about what risks they see down the line, so you can be ready for them and everyone can have as much time as possible to prepare and adjust.

User Story

As a [user role] I [want/need/can/etc] [goal] so that [reason].

Core Principles

Use the customer’s language.

Write user stories as the user would ask for them. Don’t write your user stories as a list of to-dos from the perspective of your business. As the advocate for the user inside the building, use what you have learned from interacting directly with your users to share the way they think and talk about features and activities, not how you might organize them internally. Customers don’t care about your problems, they care about their problems.

The story is a discussion tool.

The user story is just the beginning of the conversation. Use it as a tool to start from, and a descriptor to later refer back to the conversation. Don’t try to communicate all the nuance of a user interaction in the draft of the user story alone. As Agile Alliance says: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Acceptance criteria is the result of discussion.

Similarly, don’t finalize your acceptance criteria in a vacuum before you have that discussion about what the user wants or needs with your team. Come up with a draft, but recognize that it may change. The acceptance criteria should be a result of discussing the user story with your development team, not a contract written unilaterally.

Link to business value.

Show why this user story matters for the business. This context means that the team working on each story can make decisions with the big picture in mind, which has both the benefit of making it easier to get on the same page, and the benefit of unlocking additional expertise from your development team that can lead to better solutions. The acceptance criteria is a good place to do this, and even better if you can tie it to specific metrics.

Checklist

1. Can your user story provide value independent of other features or stories?
2. Can your user story be implemented in multiple ways? Define the results, not the method of achieving them.
3. Does your user story communicate how it is valuable to the user?
4. Does your user story have enough detail to estimate the level of effort required to implement it?
5. Is your user story small enough to be implemented in a 2-week (or whatever length you use) sprint?
6. Is your acceptance criteria a binary pass/fail? You don’t want to rely on subjective criteria.