The Three Hardest Words: “I Made This”

dish“I made this”, is what we say by implication when we publish, send, launch, perform or unveil work that is entirely our own. Three wonderful, difficult and daunting words.

We are the only ones who can choose when — or whether — to say them, whether to hit “publish”… whether to take the risk.

Solo entrepreneurs, writers, bloggers, artists, performers, artisans all know the feeling. But even in a team at a small startup, we may feel this to some degree because we may singlehandedly represent some entire aspect of a company, a product or a service.

Our work represents us. Once we unveil it, it is out there and usually can’t be retracted. There is no-one else to stand behind it, to share the blame or the praise. No large corporation to take the flack. No anonymity. It’s like publishing a condensed version of ourselves; a snapshot of what we are currently capable of, warts and all, for the world to see.

It takes nerve to accept feedback – good, bad and indifferent – and still stand by our work, to discuss potential improvements to it, or the inevitable choices we could have made. There is no perfect launch and nothing is ever truly “ready”.

The crucial thing is realising we did our best at the time, that no-one is 100% correct, and still being glad that we put it out there. It takes guts to realise we will inevitably want to retract, delete, smash it to pieces, or to endlessly correct it based on feedback — or the perceived feedback of indifference — but to keep it out there anyway, in its original form.

So far, I’ve done this with two software products I developed alone, this blog, photographs and other articles. I have friends who have done it with startups, artwork, experimental new food products, books and performance art. I’m proud to count myself among them because I think people who have done this are amazing.

I’m convinced that we learn more by putting our work in front of an audience than we possibly ever could by thinking and agonising about it in private, by tweaking it and waiting until we feel like it is somehow worthy or “ready”. Those lessons feed back into our next attempts, but only if we make our first attempts.

If you’re in doubt, it’s probably ready. So take the leap, and say “I made this”.

The Importance of Risking being Mediocre

averagelYesterday, one of my oldest school friends, an artist, said something that made me pause and think about what we risk by pursuing our own projects, startups, goals or art.

Far worse than the often talked about risk of failure, or the similarly discussed and dreamed of success, is the middle ground.

“What if I’m mediocre?!”, she said.

Rather than being something that most people fear openly, I suspect this may still be the reason why a great many people never get started and never produce their own work. Meaning, work which we publish as our own, to which we 100% attribute our own name, not that of an employer, a course or a group. Work for which we own all success, failure or other outcome.

It’s a myth that we can somehow learn enough to avoid being mediocre at some point, during a safe preparatory period, and then go out into the world and pursue success directly. And yet, I suspect most never get beyond the preparation stage, because mediocrity is always a risk.

In “Clarity”, Jamie Smart says “Discover your path by walking it”. I think we actually need to begin and learn en-route. Create and publish or share our work. Naturally, this means going through any mediocre stage in full view of people who may criticise us, but I suspect it’s the only way; through mediocrity and beyond. There is no way to avoid it, and perhaps it’s better to embrace it as an essential aspect of success.

This is why I began blogging and, as a software engineer, why I launched two apps of my own: They are learning experiences and, each time, I get better. The only way to something bigger and better is by doing real work and putting it out there.

It is also work realising that, by putting our work out there… we are already well ahead of the pack, because most never will.

I hope you enjoyed this mediocre blog post 😉

Handling Product Feedback: Listening in Detail, Acting in Aggregate

I’m inherently a pleaser. I think anyone who develops, builds or sells a product is, to some degree, a pleaser.

When I hear product feedback, I want to act on it. I want to to fix everything  and to please everyone. As it turns out, this can be a somewhat counterproductive trait.

Handling product feedback requires the maturity to aggregate it over time, before acting. Only in aggregate does it make sense. Here’s why.

Different Strokes – One person’s “must have”  feature, their preferred default value or their request to expose / hide certain controls will invoke the exact opposite reaction in another person. The new feature might even annoy them. The preferred default could be wrong. They will want the hidden feature exposed, or the exposed feature hidden again, just because it gets in their way.

Not every change or product decision will divide a crowd in this manner, but there is always a trade off between pleasing one person and displeasing another, which you can only see by aggregating feedback.

Groan or Gripe? – Is the request for something that matters, or is this just window dressing? Realising that some people will give feedback with the same insistence and intensity, whether or not the request is pivotal or trivial for them, helps me greatly when assessing the true priority. The trick is not to tell them the priority I’ve assigned in my head, or on my plan. Hearing that their niggle is “trivial” is a great way to lose them. Likewise, telling them I’m going to act with great urgency when I really intend to shelve the request can be as damaging.

It is also worth remembering that, in aggregate, the trivial thing that annoys a large number of people might be worth doing, whereas the major gripe for one customer in a thousand could be worth ignoring and losing that customer over. But I realise I’ll only ever see this in aggregate, and perhaps not as feedback comes in.

Is It Worth It? – Is the request one that will bring in or retain a significant number of users? Pleasing existing customers is crucial but, at some point, I know I have to weigh up whether that investment in time and effort is bringing in money and helping to keep the product going. If it isn’t, we’re just a day closer to the point at which the product no-longer exists.

Is it a Distraction? – Are there more pressing things that should be worked on first? This is obvious if there are higher priority items, but sometimes any feedback can be a distraction from building new features, or too many requests in one area can lead to neglect of another. Maintaining the product versus building the product out, will always be a balancing act. Again, seeing feedback in aggregate, versus new features and product development, can help.

It it on the map? – Does the request align with where I intend the product to go? Alternatively, does it suggest a new potential roadmap or feature? Sometimes, features requested even by a minority — occasionally a minority of one — can be worth exploring. Other users may not have thought of them and may respond favourably when we experiment in that direction.

Alternatively, if the request is not aligned with the product roadmap and doesn’t suggest a sensible detour, this may be a sign that a portion of users no-longer find the product a good fit, and there is a financial and functional decision to be made there: Who are we trying to please, and can we really please all of them or do we pick a subset so we can focus on them more effectively? This may even change the market  the product is aimed at.

How to act in aggregate – Other than bug reports, it should be rare that feedback from a single client or user turns directly into a task to be implemented.

More often, requests should feed into regular decision making about tasks, priorities and releases. Piling each request straight into the development backlog isn’t aggregation, it’s reaction. Collating feedback separately from the backlog, reviewing it regularly and then adding tasks to the backlog appropriately is more effective. Some requests will never reach the backlog at all, or they may only reach it once a volume of similar feedback is achieved and opposing reactions considered.

I’ve learned to realise that feedback points — but no more than points– at things I could, and sometimes should, act on. And I can still be a pleaser, albeit a slightly more mature one.