Blog

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.

This guest post was written by Anitha Pai. Anitha is the co-founder of Tokabee, an education startup that delivers cultural experiences for children to learn about the world. Prior to founding Tokabee, Anitha worked on a range of international development issues including financial literacy programing for the urban poor in India, primary school education programs in the Middle East and Africa, and cross-cultural exchanges in the US.

Creating and sustaining great company culture is something every organization should be thinking and talking about. As a critical factor for success, ignoring it just isn’t an option. I’ve worked for organizations with a variety of missions and organizational structures; I’ve witnessed some that have gotten it right and others that have struggled to inspire and guide employees to engage in the greater good.

At CultureCamp DC, I wanted to learn about how to develop great company vibes, regardless of an organization’s purpose. Hosted at the OpenGovHub offices on April 29, 2015, CultureCamp DC brought together a group of culture enthusiasts from nonprofits, government, consulting, startups and others to talk about organizational culture. Participants pitched and led session topics based on their interests and experiences, rather than their areas of expertise. The topics ranged from “documenting culture” and “introducing security in an open culture” to “creating culture change from the bottom-up.”

Using the unconference format, the day’s schedule was self-led and the sessions flowed. In each of the sessions I attended, conversations looped and pivoted in response to ideas from the group. While we started chatting in one session about struggles with a “culture of sacrifice” in one nonprofit, attendees then shared ideas in recruiting for “culture fit” and later we moved to real-life examples of group norming. Forget the stale presentation or discussions where one or two people dominate the conversation, this conference observed the rule of two feet. If you weren’t learning or engaged in the conversation, then you moved to a place that could make it happen.

With more than 20 sessions, participants presented challenges, proven techniques, and even games around creating collaborative culture. To support the participatory nature of the event, we embraced the four key principles of an unconference: 1) Whoever comes are the right people; 2) Whatever happens is the only thing that could have happened; 3) Whenever it starts is the right time; 4) When it’s over, well, it’s over.

Here are my top 3 takeaways from CultureCamp DC.

1. What is organizational culture? We’ve all heard success stories from companies that are consistently voted the best places to work, but I wanted to learn more about how people were identifying and fostering collaborative and open culture.
   
   To start, a few themes emerged from the sessions that I found helpful for defining the term. Organizational culture is an ongoing conversation that reflects the values and behaviors of the people within an organization. It might be directed by the company’s founder or senior leadership team, but it is much more powerful when it is crafted from the collective experience.
   
   Culture expresses itself among individual employees and teams, and it can generate a number of subcultures within a large company. A company’s culture should be aligned with its core purpose. It is sometimes codified through a formal document or put up as wall décor; yet, its potency is in the informal way that the culture is lived across the organization.
2. How can culture change? Often times, we’re not at the helm of the organization and the place we work has been around for a lot longer than we have. Under these circumstances, I was curious about how an individual can initiate a shift in culture, especially when key members of leadership are not onboard or are unaware of the need for change. It’s a situation that I and others around the table had found ourselves in at different points in our career.
   
   We talked about the tactile things that we can do to turn things around. While there is no magic bullet, presenting research or internal data can be an effective way to initiate the conversation about culture change. Using studies that point to the financial benefit of positive work culture might be one way to get decision-makers committed.
   
   Collecting data within the organization through employee satisfaction surveys can be another way to expose issues and open up dialogue beyond the grumbling at the water cooler. If it’s done in a manner that responds to the perspective, incentives, and habits of those who are resistant to change, then it can create allies and encourage collaboration while creating a more positive work culture.
3. What should leaders do to cultivate great culture? As the co-founder of an education start-up, I wanted to learn the how-tos of creating and cultivating a great work culture during our company’s initial phases. I was curious about how to get it right with our team, so that we could avoid the pitfalls that others have experienced in creating an open, collaborative and mission-driven culture.
   
   As organizations grow and employees transition, so does organizational culture. If you’re lucky enough to be in the initial stages of a company, start the conversation early and encourage continuous dialogue so that the culture reflects the company’s inevitable evolution. When there is a shift in culture, it is useful to make it explicit to avoid confusion or disengagement.
   
   Employees appreciate authenticity and vulnerability from leaders. Leaders aren’t expected to get it right every time, but by asking questions and creating opportunities for continuous feedback and engagement from all levels in the organization, leaders can foster an environment of great culture.