The Secret to Turning Ideas into Working Features

When we talk about development process, we tend to focus on process artifacts and rituals like tickets and sprint planning meetings. But how does a ticket become actionable in the first place? How do you leave a sprint planning session with enough knowledge to start development? That piece can be less clear.

The secret? Definition.

In this post, I'll walk through an example from a recent project that illustrates the unheralded but hugely important definition process.

The project: We designed and implemented an email builder application for iContact, an email marketing platform.

The Viget players: Me (product manager), Brandon (UX), David (developer).

The iContact players: Angela (product owner), Laurie (QA lead), Mark (developer).

Here's how that feature went from roadmap to reality.

Step 1: Get on the Roadmap

Early on, we collaborated with iContact's product team to define the product roadmap. We knew we couldn't implement all their ideas in three months, and they were great about doing meaningful prioritization.

The roadmap started as a Google Doc, with features and user needs briefly described and grouped into MVP, Stretch, and Post-MVP buckets. Then we created a Github Issue for each high-level MVP feature, and roughly plotted out the expected order.

One MVP feature: "Users can run spam check while building an email."

Step 2: Define

A few weeks before we planned to implement the feature, I asked Angela to write up the spam check flow's details in a Google doc.

After reading the doc, I did a Google Hangout with Angela and Laurie so I could ask questions until I understood all the details. They also surfaced an additional permutation of the flow.

I then created a new Google Doc to capture my understanding. Brandon read the doc and created a diagram with a few wireframes to make it easier to digest and discuss the complex, branching flows.

Everyone reviewed the doc and diagram, adding comments to the doc as needed. Then we did a group Hangout to further clarify the details, including removing one scenario, and so David and Mark could discuss the API implementation.

I updated the doc once more based on the feedback, and we deemed the feature defined and actionable. I updated the Github issue, referring to the Google doc for the canonical definition.

Step 3: Implement! (And refine definition)

A couple weeks later in sprint planning, we added the spam check issue to the sprint for David to tackle. Even with all the definition we had done, he knew there would be loose ends to work through during implementation with Mark and Brandon via Slack, Hangout, and in-person conversations.

The Importance of Definition

Process doesn't work if it's an end to itself. A ticket is only actionable if everyone already understands the feature's details. A sprint planning session is only useful if we're slotting in actionable tickets.

As the spam check example shows, we gain this shared understanding and make tickets actionable through collaborative definition. That part of the process is often overlooked, partly because it doesn't neatly fit into a single ritual or artifact. Definition for one feature can span multiple discussions, docs, designs, and even user testing sessions.

One of my favorite illustrations of definition's elusiveness is this UserVoice blog post about their product development process. In the post, Richard White details the artifacts and rituals in their Trello-focused process, including six Trello boards and various meetings where cards get moved.

But how do a card's details actually get fleshed out? Way down in the post, almost as an aside, Richard writes:

"It’s worth mentioning that myself, our Head of UX & PM will often have impromptu 3 hour meetings where we have in-depth design discussions spanning multiple cards on the Planning board. ... These are some of our most productive (and for me: most fun) meetings that we have. Outwardly they may even seem less than productive as we often end up coming full circle on a design decision and end up right back where we started. But really it’s a (positive) sign that we truly understand the trade-offs we’re making with the path we’ve chosen: we’re making a decision from a position of understanding rather than blindly rushing in."

"Impromptu" sessions that "seem less than productive" but lead to "a position of understanding" — this is the often-fuzzy realm of definition.

Don't let that fuzziness make you uncomfortable. Definition may not happen in neat, easily ritualized ways. But it's the key to an effective product development process.