A company’s most precious resource is its developers’ time.
That’s according to Senior Product Manager Kris McKee, who works at Optimizely, a data and experimentation platform for businesses. McKee said that communication is at the forefront of each mapping session her team holds. The sessions themselves are focused on outlining use cases and solutions as they relate to consumer issues, with the ultimate goal of internal contributor buy-in.
“After all this writing, commenting, sharing and collaborating, our hope is that we have gained complete alignment among the key stakeholders,” McKee said.
Such processes aren’t limited to product teams at Optimizely. Across Austin tech, engineers and designers must outline problems being solved and align expectations, taking audience, internal teams and general company objectives into consideration.
As project needs inevitably shift throughout the process, the following professionals explain how some priorities simply don’t — and can’t — change.
Customer-facing team members share insights and feedback based on customer interactions in Optimizely’s quarterly road mapping session. Unrestricted and comment-friendly Google Docs serve as a vehicle for team alignment and transparency, according to McKee.
When developing a product roadmap, what steps do you take to ensure there’s alignment across teams from the get-go?
I am lucky that I work on a technical product that requires a strong understanding of the technical use cases our customers implement daily. To obtain alignment early in the process, we ensure an open and transparent dialog in everything we do. Every time a product manager has a customer meeting, we share the meeting notes with the entire firm via a dedicated Slack channel.
On a weekly or monthly basis, each PM sends a company-wide email outlining key usage data and developments for their product area. Finally, representatives from every customer-facing team in the firm are involved in our quarterly roadmap process. With this foundation of constant communication, there are few surprises when a new product feature is proposed.
How do you maintain that alignment throughout the development cycle?
Our motto is get feedback early, so we can pivot early. There is no single genius here.
When a PM first starts work on a customer problem, they will create a simple use-case document that outlines the problems to be solved. PMs, designers, engineers and solutions engineers weigh in on this document. Next, the PM will expand the document to a more formal product requirement document (PRD), including revenue and usage estimations, line-by-line requirements and the final design.
Once the PRD is complete, our PM team holds a formal PRD review meeting. By the time this meeting happens, most people relevant to the project have already read the document two or three times and added comments.
Our engineers have a similar process. Our technical design document outlines technical design considerations from start to finish, including an outline of necessary Jira tasks and the expected order of completion.
After all this writing, commenting, sharing and collaborating, our hope is that we have gained complete alignment among the key stakeholders. Once the engineers have started development, any further changes will be implemented in a future iteration of that feature.
We find balance by breaking the projects down into small pieces.’’
As project needs change, how do you re-prioritize the product roadmap and keep teams aligned?
The ability to be nimble and re-prioritize as necessary is key to staying relevant and ensuring our features meet our customers’ needs. However, our most precious resource is our developers’ time. Therefore, once a project has started development, we limit changes.
We find balance by breaking the projects down into small pieces, ideally containing two or three weeks of work each. A large project may be broken up into two, three or five chunks, each two-to-three weeks in length. This gives us space to iterate without disrupting the development process.
According to Volusion Principal Product Manager Shehaam Houkal, explaining the reasoning behind a product change just once isn’t enough: Data should be at the root of every decision made. Houkal said her team regularly digs into metrics like support costs and avoided account cancelations.
When developing a product roadmap, what steps do you take to ensure there’s alignment across teams from the get-go?
It starts with being clear about what business goals and customer pain points we need to solve. Having key stakeholders involved in the discovery is crucial. They will not only bring the diversity of perspectives you need to sculpt the roadmap, but they will also clue you into support costs and risks you may not have otherwise identified.
Make sure teams understand that, ultimately, a feature on the roadmap is there to solve a problem. Remain flexible on the solution as new information comes to light. Nobody likes to be tied to a feature.
How do you maintain that alignment throughout the development cycle?
Sharing data regarding how well you are solving the problem is key. Make sure everyone knows why you did or did not stay the original course. For example, we share data relating to the number of new clients we signed and how many cancellations we were able to save because of a new feature.
Then, turn that data into actionable steps. Did you see clients use the feature? If not, add an onboarding flow to point it out and explain its benefits. Did you see new business as a result of a specific implementation? Double down on enhancing that feature set to see if you have hit diminishing marginal returns.
Make sure everyone knows why you did or did not stay the original course.’’
As project needs change, how do you re-prioritize the product roadmap and keep teams aligned?
It really depends on how drastically new needs have changed. If you have to do a complete 180-degree pivot, explain the data that illuminated the need for a change. You’ll need buy-in from senior leadership, as the pivot may have staffing and training implications. Don’t be afraid to start the process from scratch to challenge your previous assumptions.
If it’s not a complete 180-degree pivot, start with why the need changed. That information should be at the heart of how you re-prioritize the roadmap. The nature of the need will also affect how you reprioritize your existing features and introduce new ones. It takes time to re-adjust and build a new habit. Ensure alignment with additional check-ins and sync meetings.
