Creating a simple framework for product design

'You're creating a framework for Product Design? What would that look like? Why would you do that?'

All valid questions. I did make a framework for *basic* product design (lowercase P, lowercase D), and I'll tell you why: product design is usually too complex. Now, before anyone shouts 'but product design IS complex!' - I know how complex it is. But imagine being in a workshop with 10 stakeholders, all with different understandings of what 'product' and 'design' is (as well as numerous variants on what 'stakeholder' means too) and having to stand there as the Creative Lead and explain the complexity of product design and why it's important. Now imagine you're not working at Facebook where everyone is mostly on the same page with the mission ahead, but you're in a room with divergent stakeholders - some of whom may never have met the other stakeholders - may not even understand what that stakeholders department might be or what it does. I've been there and it's sometimes great, and sometimes awful. 

Workshops are a great way of quickly identifying the problem either at hand (which the proposed product will solve) or within the team (which is more complex to solve), and over time I've amassed a tool kit to aid communication. IDEO cards are great for discussing different ways of understanding problems, for example. Gamestorming is a great manual to have on hand to facilitate group discussion and break down departmental language barriers. A Business Model Canvas is a great way of seeing the impact of product decisions, and can allow a creative team to see beyond the wireframe or aesthetic into 'how we get paid' territory. I've even built discussions around Oblique Strategies (don't try this mid-workshop in a panic). They're all tools for aiding discussion, and they're all good at aiding discussion. They work. That's why they're popular. 

The problem I've found with using these kind of frameworks in Workshops or in teams I've managed is exactly what makes them so strong. They inspire discussion, but they usually deliver less actionable results. The outcome of the discussion can be many ideas, but sometimes the important questions haven't been addressed - like 'what problems does it solve?' or 'can we actually deliver it?'. I love that Gamestorming can deliver moonshots, but when your team are whiteboarding a new product vertical to replace an existing one - the need sometimes for shrewd questioning becomes more important that big sky thoughts. 

This framework is broken down into five core elements - five colour coded elements which are pretty straightforward for any existing product team:

Brand
User Experience
Concept
Commercial
Quality Assurance

Each of the core elements is designed to ask a series of 10 awkward questions that you'd expect a really exacting/mean VC to ask in a funding meeting. Yet the framework is asking the questions - not a physical person, so it's harder to get annoyed with the person asking the question and then get resentful or defensive. It's Cards Against Humanity for Product Designers, but YOU personally answer the awkward blanks. 

The framework can be used at any time in the product roadmap. The earlier it is used in the product cycle, the answers to the questions generally are less passionate and more vague, yet a designer may become more aware of the commercial strategy. A PM may become more aware of testing complications. The later the framework is used in the product cycle the more hard the questions are to answer in honesty. They're tough. I'll give you an example. 

"How will the product be iterated?" is a simple enough question. Yet it's always been one of the more divisive questions in workshops I've been in. Depending on at what stage of product cycle the question is asked in, it can mean any of the following, or cause any of the following to be asked:

"How are we going to support this thing once it launches?"
"Do we have a team big enough to keep this updated on an ongoing basis?"
"Who is going to be in charge of it after the launch?"
"Do we have to hire more people?"
"How are we going to handle legacy tech or product debt?"
"Does the development team feel they know the full requirements of supporting this code base?"
"How do we fit this product into an ongoing test schedule?"
"What is this products expected lifespan?"

Answering those questions in a group can cause conflicting answers, and sometimes can draw out seething issues, (to paraphrase a stressed and tearful PM I saw answering this question with their team) "I know it's going to be up to me to support this thing like it always is. I'm sick of products getting dumped on to my schedules after launch". In this case the team were shocked and tried to work out how their products were relying on one person so much - and the answer was technical debt. The PM in question was the only one in a new evolving team that understood the legacy CDN infrastructure. 

I've used these cards by single suite to target specific issues, but I've also placed all 50 face down on a conference table and encouraged everyone in the group to pick a card at random and answer it to the best of their ability before asking the group to contribute their answers. Often we'll write the answers on a whiteboard too if there is confusion or conflict. Or sometimes we use them to draft a mission statement at the beginning of the product, using it like a backbone during production - allowing for quick and easy product goal retrospectives and requirement tracking. 

So as I was saying earlier, product design is too complex. It's too complex as too often we don't ask the questions we need answers to make product design simple. This is a framework to help you ask the questions that you were too afraid / busy to ask.

And of course, once you have the answers to those questions, you can get on with the complex job of product design. 

If you would like a copy of the framework documentation please contact me here.