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. When you have clear goals, priorities and success metrics it 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 implementation will reflect these goals better. It may feel subtle, but over time translates to better, more consistent product quality.

The best organizations plan but can also 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 favorite framework is Now/Next/Later because of its simplicity.

Roadmaps should be lightweight, flexible and become less precise 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 have an up to date list of the top three things that each area is focused on. These should be specific and “roll up” – e.g. a project has top 3 things, the division has top 3 things, the company has top 3 things.

Top 3 things adds a level of simplification to larger roadmaps so that people outside the team can understand priorities quickly and precisely. It forces the teams to decide what’s most important and is a process can scale across large organizations.

The top three things should be specific, have a clear outcome and refreshed at the end of every sprint or planning cycle (typically 1-2 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 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 (production code) and clearer requirements for design and engineering teams.

These documents are short 1-2 page descriptions 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. One pagers should cover the goals, metrics, problem space and solution options 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 review 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 if we met the intended goals.

When doing retros it’s important to separate learnings from the development process and the outcome as there are cases where quality product development doest not have a good business outcome because we intentionally took risk. In these cases it’s important to celebrate good work, and share learnings. If risk taking is not celebrated 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.