Main

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.

First, it bears mentioning that this is a key challenge of starting a new business. If you can’t find interviewees to talk to, you won’t be able to find customers to sell to either. Spend some time to get this right, because it’s not a problem that simply disappears after you validate your market.

There are two main approaches to doing customer interviews. Pick an approach depending on whether you are trying to optimize for calendar time or clock time.
Calendar time is the elapsed time between beginning and end of a task. Clock time is the person-hours spent on a task.

Identify Your Time Constraint

If you are working full time and you have savings to last you a month, you’ll want to optimize for calendar time. If you’re working on a side project in your limited free hours between work, sleep, and family time, you’ll want to get as many interviews as possible done per hour of clock time, and ignore the time spent waiting for responses.

For Calendar Time

If you are trying to maximize the number of interviews you can conduct before a deadline, it may take more of your clock time. But you will get more responses in fewer days if you go to where your customers are and try to talk to them. Get out on the street with a clipboard and find people who look like your target customer. Ask them if they would mind helping you with a research project by answering a few questions. If your target customers aren’t out on the street, figure out where you can find them and go there. Product for restaurant owners? Go restaurant to restaurant and ask for the manager— just don’t do it during mealtimes. Product for dentists offices? Time for an office visit— followed by 10 more.

The advantage of that approach is that you can you can approach many potential interviewees in a short period of time. Even if your success rate of interview agreement is lower, you will get more interviews in a few hours of being where your customers are than you would in a day of sending warm email introductions. Increasing the number at the top of the funnel pays dividends.

For Clock Time

If calendar time isn’t an issue, but your clock time is scarce (e.g. you’re working full-time), then you need an approach to maximize the number of interviews you can secure and conduct per hour of your time. The key here is to get warm introductions from people you know to people that you don’t know but who fit your customer profile.

Find 2nd-degree connections on LinkedIn who fit your target persona. Ask friends to reshare a message on Facebook: “I’m looking to talk to busy professionals who are health-conscious and want to cook at home but don’t have time to arrange it.” The potential interviewee is much more likely to take your call because the request comes from someone they know and trust. We’re more likely to help a friend of a friend than some random person on the street.

Questions about using this approach? Suggestions for others doing customer development? Comment below or schedule a free session for 1-on-1 help during office hours.