Tagged with: ‘product’

Posts: 7

This is how you package consumer goods

Yesterday I was in the market for some plughole unblocker. We’ve moved places recently and I forgot to put this useful little thing in our shower.

So I head into Tesco and — eventually — I find the section for bleaches and plughole unblockers.

I know that Mr. Muscle is a popular brand for this product, so I look for the logo.

Bingo. I find the Mr Muscle.

photo of Mr Muscle among other products

Just as I’m about to pick up a bottle, I notice the bottle next to it. It’s called Buster — a brand I've never heard of.

photo of Buster — a challenger brand

Here’s what happened:

  • The packaging for Buster does a great job of capturing my attention. It makes a bold assertion that’s relevant to what I’m looking for -- that this product is much better for bathrooms.
  • The packaging entices me to find out why by picking-up the bottle and turning it around. In two, very succinct bullet points, it pitches why Buster is better.
  • By this point I’m already holding the bottle of Buster and since I had just been sold on why it’s better for what I needed, I went ahead and bought it.

Without realising it, this nifty bit of packaging had moved me right through the marketing funnel (Awareness > Consideration > Purchase) in around 10 seconds.

Of course, the irony here is that both of those brands probably come from the same company — be it, Procter & Gamble or Unilever et al. This is how the consumer packaged goods industry works.

That though shouldn’t take anything away from this being a nice example of how to package an alternative product, in a market that is largely dominated by recognised household brands.


Questions to ask your design work

Last month I spent some time updating my portfolio. As a product / user experience / web designer, it can be quite tricky to present your work to others.

The rock star visual designers of this world can get away with presenting screenshots of their stunning visual work — job done, money due.

But if your day-to-day consists of making user flows, interaction designs, napkin wireframes, trade-offs, A/B tests, and minimum viable products, then you — like me — need to do a bit more groundwork to do the show and tell properly.

It’s not so much the what, but the why and the how.

With this in mind, I decided to structure my portfolio around the questions I ask myself when looking at other products and services:
A user experience, product design portfolio layout

1/ What was the context?

Was this a piece of work for a fast moving startup or a 100 year old family business? Setting the context lays some good foundations for answering the questions around what you did and why.

2/ What problem were you trying to solve?

The cornerstone of successful design projects, is making sure you’re solving the right problems.

In this section of my portfolio pieces, I found it useful to pull apart the problem I was hired to solve.

Sometimes the problem definition is a bit blurry i.e: Do we really need to make the sign up process faster? Or - to convert more prospects - should we enable users to access features without committing to signing-up first?

3/ How did you design the solution?

Here we deep dive right into how you designed the product / interface / solution.

Unpack how you approached things. Show rather than tell. Let us see what you made.

Did new insights emerge as you moved through the project? If so, lay them out here — tell us how you responded.

4/ Review the above

The final section of the portfolio answers:

  • How did it go?
  • What impact did the solution make?
  • What happened when your work reached customers’ hands?
  • Can you surface some feedback or data that points to show your solution is working out?

Arguably, the biggest thing you bring to the table as a designer is your ability to render an optimal solution — and answers to these questions go a long way in revealing how you do that.


How to Pitch Your Product to the Press

Last Tuesday I popped in to DoES Liverpool to see Matthew Hughes give a talk on how to pitch your product to the press. He’s a tech journalist at MakeUseOf — so he had some lessons to share from the other side of the table.

In no real order:

  • Be as concise as possible - journos receive mountains of product pitches each week.
  • Sounds stupid but: There’s a difference between product pitches and press releases. The former is an anchor to entice the journo to sign-up for your product, check it out and write a review.
  • If you have notable investors > name drop them. This adds validation.
  • You need to entice the journo - lead with the problems you’re solving.
  • Personalisation is important. Do your research on the journo. What have they written in the past that might make them want to write about your product?
  • Gifts are cool, but not bribes $$$. UPDATE from Matthew: “Should probably clarify I meant gifts with no monetary value though, and after an article has been published. ;)”
  • Obvz grammar is super important.
  • Journos like phone numbers for follow up - so share yours.
  • Don’t talk about yourself (founders) - especially if it’s a product pitch.

Bookmarks:

  • press.farm find journalists to write about your product.
  • blonde20.com good PR agency. Do retainers from around £4,000 a month — much more competitive that London agencies we’ve spoken to.
  • uber.com/presskit Uber’s press kit is a good example.

You produce results: Learn from these

It’s nearly been a year since I joined Fruitful - a fintech startup that’s working to rethink how savers save and how borrowers borrow.

Since then we’ve been through a significant product redesign, a complete branding overhaul, a successful soft-launch and a customer response that has more than overwhelmed us. With customers investing with Fruitful from all over the globe, it’s clear that people are in search of an ‘alternative’ that offers fair interest rates, secured lending and the flexibility that we should expect from a modern investment product.

So as we venture into 2015, I thought I’d share a handful of the lessons that I’ve learned and have considered tattooing to my forehead.

Mostly product focused, take from this what you will:

Integrate Around Concerns

When working with a team of designers, developers and content people, there’s always a temptation to separate tasks by role, such as a ”design” todo list and a ”programming” todo list.

The problem with this approach is that it’s difficult to assess progress from separate to do lists or issue backlogs. On top of this, there’s an increased operational risk. Since the QA effort stutters, stopping and starting as each role’s to do list is completed, you run the risk of failing to test the feature as a whole.

Learning from this, we’ve formalised a workflow that integrates arounds concerns. Instead of organising around roles (e.g. design tasks, programming tasks), we organise around areas of concern (e.g. registration form, email receipts). As Ryan Singer puts it:

Marking one piece “done” is powerful because it requires design, programming, support and review to integrate around a specific point in the product.

Whenever a list is finished, it shows a piece of the product is ready to review and mark ”done”. It feels great to know one part of the product has no remaining contingencies. It’s ready to go.

Minimum Marketable Product

Give that I:

  • joined the project just after its inception and
  • had limited experience in the mortgage market and
  • was (initially) unsure of its legal and regulatory commitments

I failed to ask some important questions about minimum marketable product (MMP).

And yes, I prefer MMP as it underscores the importance of building something that is sought-after, by customers, (marketable) vs. something that is viewed merely as feasible, by the company, (viable).

On top of this, MMP forces you to:

  1. Think about the important areas where you should adding value (i.e. your differentiators) in conjunction with:
  2. Working hard to develop those areas, so that they reach a high level of finish, giving you a better opportunity to win the hearts and minds of your customers.

Given the choice, I’d always favour a good job of half, than a half-assed job of all. Much later than I should have, I noticed that as a team, we were stretched and chasing our tails to reach our fast-approaching launch date.

After some belated conversations about the product’s essentials, and a hash through our priorities, we were left with a much more slender view of our MMP. As a result, we were able to achieve a higher level of finish with features we developed, we were less stretched, and we shipped quicker.

In short: dream big, implement small.

90% + 90% does not equal 100%

The ninety-ninety rule lassoed us a number of times:

”The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”

Tom Cargill, Bell Labs.

In short: be very careful that you do not underestimate the time, effort and energy that the remaining 10% will demand from you and your team.

Deadlines are hard to reach. And they’re even harder when you mis-judge the magnitude of your plans.

Go broad before you go narrow

Common talk in the world of human-centred-design, but this is useful in most walks of start-up life.

When you have to make a decision, go far and wide with your ideas, no matter how daft or bizarre they sound. Superglue the Devil’s advocate mouth together while you go broad with your thinking. You never know what inspiration you might draw from this left field, brainstorming effort.

This method of thinking has helped us overcome some real challenges and produce far superior solutions and ideas.

Effective concepts often draw on multiple sources of inspiration and thinking, and this process will help you along your way.

Finally: on Venture Capital

“It’s all about burn rate, about burn rate, slow spending...

Fingers crossed I’ll find more time to write and share what I’m learning in 2015. I hope you do too.


Product Design Process

When we have a new product idea (and are lucky enough to have the skills and tools to execute on it), it’s often more than tempting to jump in with two feet and start building the thing. Before we know it, we’re pitching the hows before whys and problem solving becomes a battlefield of miscommunication. As a result, our product concept becomes more complex and less focused.

Over the last few weeks, I’ve been investing a lot of time and energy into a product design process that we’ll be using for an upcoming project.

I insisted we made investments in our process and put this case to the team:

We’ll Make a Better Product

The main reason for using a product design process is ‘to make a better product’. To query our definition of a better product: a product which outperforms its competition by solving its customers’ problems in a more simple and effective way.

We’ll See Where Value Can Be Added

Distilling the big problem that our product is solving into situations will help us visualise all the moving parts and figure out where value can be added.

Ryan Singer writes a brilliant piece on situation value:

Suppose a team is building a “file versions” feature. Two situations define the value differently and lead to different designs.

In one situation, a person catches an embarrassing mistake in a proposal and wants to know who to blame. In order to do this, they need to see information about intermediate versions. They value the product telling them who made what changes and when.

On the other hand, consider a situation where they want to send the latest version of the proposal to the client. They don’t care how it got to its current state. They just want to send the correct file. In this case intermediate versions have no value. The user just wants to know where the latest version is.

Different situations = different values.

Defining situations will align us as team and conversation will be more constructive and focused on the task at hand; getting users from A to B.

In the absence of code we can quickly iterate through our best ideas, fitting all of the moving parts together. This will maximise our potential of designing a product concept which is simple, useable and more effective in its approach.

We’ll Sing from the Same Hymn Sheet

We’ll waste less time and energy mis-communicating and voicing logical speculation. Instead, we’ll be solving real problems based on real situations.

We’ll know the right time to discuss problems and when it’s right to discuss solutions. Better still, we’ll be contributing ideas from our respective areas of expertise, which will open up new opportunities and unblock us.

We’ll Think Conceptually

Freeing ourselves from code will help us to problem solve in a more abstract way. Code is high fidelity; like cemented bricks. Better to think solely about the product in its conceptual form with something low fidelity, like paper mockups.

The beauty of problem solving on paper is that it’s quick and easy. We don’t need to be artists to present our ideas to each other. What’s more; we can quickly hash-out numerous iterations of a design pattern or technique and pitch them against our view of a better product.

We’ll Build a Better MVP

Once we’ve formulated our product concept, we can outline features that we want to exclude for 1.0; this will form our minimum viable product (MVP).

We’ll know that the MVP we’re building, is in fact, the foundations to our product concept. We’ll waste less time as everything we build will count towards the whole. We’ll loop through less iterations as the UX will have a solid direction, cemented on real world problems.

So far…

The process has already helped us in the areas above. We’re still learning though and adapting to a new workflow is always daunting. We’ll put the process through its paces a little more and I’ll share it on here once we have something to show how effective it is.

In the meantime if you’re working on software projects and care about what you ship, I’d suggest you checkout Rick Hickey’s talk on design, composition and performance as well as Ryan Singer’s post on the Vital Elements of a Product Design Process. Both have been central to designing our product design process.’