Aadil Mamujee

This post is a collection of some product development practices that I think are valuable. It’s not meant to be an exhaustive list, just a collection of thoughts.

Goals and Planning

“Plans are worthless, but planning is everything”

Dwight Eisenhower, 1954

Planning allows teams to get aligned and having clear goals, priorities and metrics for success creates a shared understanding of what is important across an organization. If more people understand the ‘why’ behind goals and how these goals ultimately roll up to the company’s mission then the product details reflect these goals and values. It feels subtle, but over time translates to better, more consistent product quality.

The best organizations plan but are also able to abandon plans or adjust quickly based on new internal or external data. Many large organizations become rigid and slow, although perhaps more intentional, which is often the argument against medium or long term roadmaps.

Roadmaps: Now/Next/Later

All teams should have a public roadmap (an extension of planning) and my favourite framework is Now/Next/Later because of its simplicity.

Roadmaps should be lightweight, flexible and become less precise as they look further in the future. When all teams use the same format (and this is accepted across the organization) it’s easier to roll up work across teams. It’s even easier if all teams to use the same tool (particularly for managers of multiple projects), or if there is seamless two way information transfer between roadmapping tools.

To help determine priority, which is ultimately an ordered list, I like to use an Impact vs. Effort framework (taking into account Risk as well). Impact is the potential value to users and the business, and Effort is how hard it is (T-Shirt sizes like S, M, L, XL are an easy way to visualize).

Top 3 Things

At every level of the company write down the top three projects at any point in time and share them publicly.

This is a simplification layer on top of roadmapping to make it easier for folks outside the team to understand their work, quickly. It also acts as a forcing function for teams to decide what’s most important It’s a process can scale across large organizations and roll up nicely from teams, to divisions to the top of the organization.

The top three things should be specific, have a clear outcome and refreshed at the end of every sprint or planning cycle (typically 2-4 weeks).

Shaping (“One Pagers“)

Thinking is cheaper than making, and crystal clear though upfront can save multiples of that time (and cost) down the line.

One pagers should shape problem spaces into a set of solution spaces and assess the viability of these solutions to solve a set of user or business goals. It’s a collaborative document typically assembled by product managers with engineers and designers contributing. This process helps build alignment between the team, allows multiple solution spaces to be explored, and ultimately results less discarded work and clearer requirements for design and engineering teams.

These documents are short 1-2 page descriptions of the feature that anyone across the organization can read (as little jargon as possible) and get a sense of the value and the scope of the project. They should cover the goals, metrics, problem space and options for solutions with a recommendation of an MVP.

Burndown Lists

Burndown lists are simple, ordered lists of all the tasks/bugs/polish that need to be completed before we launch a feature (can be any version of launch – internal or external).

These are typically assembled when a large feature gets close to launch and the ‘launch line’ is a moving target. Once everything above the launch line is completed, the feature can launch. It’s an excellent system to help with prioritizing what is necessary for launch in a binary way, which simplifies the decision process.

Burndown lists a simple, visual powerful and motivating tool for folks who are getting ready to launch a feature. Checking off things that get you closer to the launch line is very satisfying 🙂

Feature Reviews & Retros

After launching a feature (especially Large or XL: projects) it’s important to get together to reflect on the project. This allows teams to step back to reflect on the process, celebrate their work and their colleagues and codify learnings for the next project. I prefer doing retros once we know the outcome (metrics) of the feature to see we met the intended goals.

I could also see an argument for separating this into two pieces, the process and the outcome as there are cases where quality product development (for a risky feature) do not achieve goals. In these cases it’s important to celebrate good work, and share learnings. If taking risk is not accepted by the organization it will be avoided, which stifles long term innovation.

Dogfooding

Use your product. At every company I’ve worked at, a significant portion of the people who work on the products are not regular users of the product outside of their daily work.

Especially for consumer products, the more people at the company who use the product like ‘real users’ the better the product will become. Using products creates empathy for customers, because you’re a customer, and helps improve product sense (although increases bias) and find corner case bugs.

It’s also a powerful cultural force, and I think that leadership, in particular, should lead by example by being power users of the product (s)– the product something everyone in the organization has in common.