If you are a product guy, stuck between ideas of features and the tech team frustration, read this.

What’s your job as a product owner ?

There are many things to do, but let’s focus on the “idea to code” part.

• You gather ideas, prioritize and groom these ideas (define, communicate, evaluate all risks…).
  IDEAS ✅
• You come up with wireframes, high-fidelity mockups, then a prototype, and user stories for the tech team. Now it gets tricky. From Wireframes to User Stories : It gets blurry 🔴
  Why ?

Wireframes are closing doors

Wireframes are not flexible enough to allow changes. By nature, they are too detailed and lock the team into a specific solution before the team (UI designer & developers) can even think about it.

Solution: the Shape

Add one step between wireframes and user stories: the “shape”. It’s a rough sketch of the solution, not detailed, but gives a direction. This leaves designers room for creativity, focused on the problem to solve, not your solution. Compared to a simple description, the shape provides boundaries which help scope the work in the teimframe required.

Note : Experienced designers may be able to challenge and re-think a Wireframe, but that’s more difficult than starting from scratch. Let’s try to help everyone here !

Example

• customers ask to “add a calendar” Proper calendar like Google Calendar are 6 month works at least. We have a 6 weeks cycle.
• User research shows: read only is enough. 2 month timeframe fits all needs. Let’s Shape it
• Now, the designer has a loot of freedom to come up with a solution, and developers can start working on it. Developers can challenge the design to help respect the timeframe.

Key points of a Shape

• Draft : shaping style must remain in a draft style. Not specific.
• Direction : shaping must show the solution, and its components. Everyone must understand what it’s going to be.
• Do not : shaping shows what it is not. Where to stop. Time VS Perfection.

Skills

You need to cope with:

• design interface ideas (80%)
• technical knowledge (10%)
• business priorities (10%)

Generally, the product owner is the best person to shape the solution. If mising some of the previous skills, then close collaboration with the rest of the team is even more important.

How

Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. Basecamp, ShapeUp

Planning

First we figure out how much time the raw idea is worth and how to define the problem. This gives us the basic boundaries to shape into.
More here

Shape

Then comes the creative work of sketching a solution. We do this at a higher level of abstraction than wireframes in order to move fast and explore a wide enough range of possibilities. Use “Fat marker sketches” to force it drafty. More here

Risks

Once we think we have a solution, we take a hard look at it to find holes or unanswered questions that could trip up the team. We amend the solution, cut things out of it, or specify details at certain tricky spots to prevent the team from getting stuck or wasting time. Talk to a few experts here ! More here

Pitch.

The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations. This formal pitch goes to the betting table for consideration. If chosen, the pitch can be re-used at kick-off to explain the project to the team. More here

Prioritize with Betting

No overall backlogs ! We want only top and fresh priorities (ideas, bugs, request) on the table.

• Decentralised backlogs
  Each team can have its own backlog of stuff to do. Bugs for the tech team, features from the Support team, requests from sales prospects… The leader of the team maintain the backlog as he wants.

• Betting table
  Why is it not a backlog ? Backlogs piles up ideas no one will ever do. It’s depressing. Let’s be comfortable with the mantra: “Good ideas come back”. Every 6 weeks cycle, clear the table entirely. Ideas poping up in the coming cycle will be fresh and relevant bets. It’s important to communicate with leader of other teams to make sure the ideas are on the table, and you as a product owner will “shape” them.

For example, Support can tell you about top issues they are seeing, which leads you pick just one of those top issues to work on for this 6 weeks cycle. Then, in a future one-on-one, Support can lobby again for an issue that hasn’t yet gotten attention.

This approach spreads out the responsibility for prioritizing and tracking what to do and makes it manageable. People from different departments can advocate for whatever they think is important and use whatever method works for them to track those things—or not.

This way the conversation is always fresh. Anything brought back is brought back with a context, by a person, with a purpose.

Resources

• 📕 article from basecamp