Every company sets their bar at a different height.

Everyone wants to move fast (and break as few things as possible).

But building a robust, easy-to-use product that's reliable is also considered table stakes in the world we live in.

The curse of the MVP

The lean startup movement has led to the term “MVP” (Minimum Viable Product) becoming a commonly used phrase in product development at startups and large companies alike.

The intention of building an MVP is to validate an idea as soon as possible. It's about proving or ruling out an idea as soon as feasibly possible before developing it further or ditching it.

It's hard to argue that the concept of building an MVP doesn't make sense. Of course you don't want to spend weeks on refining your button styles or getting your typography spot-on when you are trying to direct the course of your business in the first few weeks or months of starting out. You want to be seeing if anyone gives a damn about your new product.

The problem with the term “MVP” is I hear it being used all too frequently as an excuse in later stage businesses to ship a feature before it's ready for customers.

“It's ok for now, we can improve it later, let's just get it out the door and see what people think.”

“It's good enough for now.”

“Let's see if anyone wants this first and then add the onboarding.”

It seems we live in a world where the term “MVP” now means “fuck it, ship it”.

MVPs are useless unless the purpose of pushing the new feature out is to learn and iterate based on immediate feedback from users and customers. This feedback should then guide the feature to be improved or killed, and everyone working on that MVP should be aligned on that.

Back in ye old days

Before the term MVP came along, and before the lean startup movement, many software teams worked harder to refine an idea or feature before it made it in front of customers. This often led to a slower release cycle, but often the quality of features and the user experience was higher.

Speed and quality

Having a slower release cycle can be the death of a software company. If you're not iterating and learning fast enough then it's only matter of time until someone overtakes you.

But you also can't afford to give your users and customers an experience that's anything less than delightful.

So how do you decide when something is ready to ship?

Here's a few questions we ask to help guide us at GoSquared to try to work out way around this conundrum.

Is it better than what's already out there?

If the feature is replacing existing functionality in the product, is it better than what our customers are already using right now?

Is the new

One of the exciting things about building a business is bringing together a group of people to make something from nothing.

Whenever you have a group of people in the same room, people often have different opinions and ideas. Sometimes you can have bold, potentially very hard-to-build ideas. Other times you might have simple, yet meaningful ideas for incremental improvements.

Sometimes, though, you find yourself with no ideas of your own. When you're in this position it can be very easy to find flaws in any suggestions that have already been made.

"That's great but..."

"That'll never work because..."

"How do you intend to do that when..."

While it's important to be realistic about ideas and plans, often the realism can come in too early in the lifecycle of an idea.

If you find people saying "no" to an idea too early, it can be enough to hold back a potentially great idea from ever being worked on and considered. In the long run, that's a big problem for a creative team – ideas are fragile and need to be nurtured.

At GoSquared, something we try to hold as a value whenever entering any sort of early stage creative discussions is this: start with yes.

I don't mean say yes to everything throughout the process of building a product. Crikey, if there's ever a way to build an awful product it's to say yes to everything people ask for.

Instead, what I'm saying is don't shut down potential avenues and ideas too early. Don't narrow yourself down too soon. The best solutions come from considering a plethora of options and picking the best and then refining and refining.

Next time you're in a creative meeting with your team and you find yourself wanting to criticise an idea or say "no", hold back. Hold back and think "if we said yes to this, what would we need to do?"

Start with yes. There's plenty of time for a "no" later.

Everyone has an opinion on things.

If you're in a small team and you're building a product then it's likely everyone has a deep level of involvement in your product, your marketing, your hiring, and everything else in your company.

The thing is, when everyone has an opinion, it's likely they won't always be the same opinions. People clash. Ideas are fought over. Arguments happen.

Most of these arguments and debates are good. But when you need to narrow in on a really tough decision then it can be hard to stop the discussion developing for hours. Worst of all, it can be the case that no decision gets made at all.

Decisions being deferred is how startups die a slow death. As we always like to say in the team: Act now. Not tomorrow.

So how do you make decisions more quickly when debates are going on about new features, about styling, about copy, about coding styles? Etc. Etc.

What we've found pretty handy is adopting a "scale of giving a damn". It's inspired by this slightly more sweary post from Cap Watkins of Etsy.

Essentially, for a discussion or debate that's seemingly taking longer than it should, that has no clear sign of ending, where neither side has enough data at the table, someone tries to pull out the question: "on a scale of 1 to 10, how much of a damn do you give?"

Each side of the debate figures out where they're at on the scale of 1-10 and whoever cares more (gives more of a damn) makes the call.

This isn't the answer to all of life's problems, but it's certainly helped cut a lot of conversations down from 5 hours to 5 minutes. It's helped a lot of decisions get made. And it's helped a lot of people get on with their jobs without feeling pissed off or shouted down.

No one wins an argument, after all.

Lately we've been doing a lot of thinking about the problems we're trying to solve at GoSquared.

Sketching and writing help me to get ideas out of my head and onto paper.

But talking to other people – friends, colleagues, and especially difficult-to-please acquaintances outside of my immediate circles – helps to filter through the ideas that are good from those that suck, and refine the ideas that are good into those that can be great.

There's nothing like having to explain a concept out loud and pitch it to someone. Even without any feedback, the process of turning thoughts into spoken word can be enough to refine a pitch, rethink an idea, or turn a concept upside down to make it understandable.

When was the last time you pitched a new idea out loud to a stranger? Give it a go, you'll be amazed at how much it can focus your thoughts.

If you're worried about pitching your idea to someone else, is it because you're nervous about what that person might say? Is it because you don't have confidence in the idea?

You have very little to lose by telling someone your thoughts and your plans.

Putting a product out in the world is really difficult.

It starts easy enough, especially when you're a one person show.

When you start out you can be opinionated. You can make bets. You can just get stuff done.

The more people you throw in the mix, the easier some things get. But some things get harder. Product management is one of those things.

As you grow, even to a team of just eight people (small when compared to most funded tech companies) you have eight voices and opinions on where the future of the company should go.

Here's a few thoughts on how to bring eight people together to build a great product, and ultimately a great company.

Democracy vs dictatorship

A lot of companies present themselves to the world as being a utopia for developers, designers and product people. They pitch their workplace as an environment where you can develop anything, push it live to customers, and watch as the money keeps rolling in.

Product experimentation, trial and error, and getting things in front of customers ASAP is essential. But things turn to chaos extremely quickly if you don't have a higher level vision, and an overall framework of priorities as a company.

What matters is giving everyone a voice, ensuring it's heard, and then making a decision for the whole company that gets everyone working together in the same direction. Aligning everyone is key.

Sometimes the decisions may be right, often they'll be wrong. But the worst situation is to spend weeks or months debating, and not deciding where to go next.

Sometimes you just need to make a call and move forward.

Lead, follow, or get the hell out of the way.

The loudest voice

In team discussions, there's often someone who can speak louder than everyone else – someone who is more aggressive at getting their opinions heard. Good teams building good products ensure everyone's voice is heard. Good teams ensure once everyone has been heard, that the best ideas win, not the loudest.

The most cynical voice

In an earlier post, I wrote about how fragile ideas can be. Some of the best products and features can start as barely formed thoughts that are very easy to squash with a small comment thrown in a team discussion.

You have to work extremely hard – you have to obsess over this – to avoid ideas being shot down too soon. People often err on the side of caution, and great things can often start as ridiculous sounding ideas. There are many things to laugh at in this world, but the product ideas of your team are not a laughing matter. No matter how ludicrous they seem, early stage ideas need to be listened to and given time to fully form or fizzle out on their own merit.

Don't let the most cynical voices of your team drown out the potential of your most crazy ridiculous ideas. There is a time

There's more to a company than meets the eye.

When you're using an app or a service, it's always easy to assume it's "such a simple" piece of technology. That there's not much to it, and that you could build it in a day if you had nothing else to do.

Every app, no matter how simple, requires work to build and to maintain. But the code and the front-end design are just the start.

Businesses selling software online have far more than just a codebase to maintain. But all your customers see is the 4 screens of your product they use every day.

What customers don't see is the rest of the work that goes into running an online business – The support software. The analytics tools. The internal dashboard for measuring key business stats. The mashed up tools for giving customers trial extensions when they need it. The home built email builder that makes nice emails look great in all email clients. The dev tools to get team members onboarded quickly.

Customers also don't see the other ideas you're having. They don't see the endless hours of design and development that result in features and products that don't actually end up shipping. The hundreds of sketches. The Sketch mockups you've been playing with for months for the native app you can't commit to just yet. The entire interfaces you've coded up and built but that fell short of great in the final stages so never got pushed live.

And perhaps most of all, customers never see the time and effort and exceptional hard work that the team puts into each and every feature and product iteration.

Next time you think to yourself "How is that a business? I could build that in a day!" Hold that thought and think about how ridiculously difficult the whole process of running a company is.

What you see of a business you buy from is just the tip of the iceberg.

It's a mantra you hear a lot in the world of software development.

Ship early. Ship often.

But for such a simple piece of advice, it can be really difficult to stick to.

We're trying to get better at this at GoSquared, so I thought I'd share a few things we're trying to help us ship updates and features earlier and more frequently.

Ship early

• Be clearer before writing a line of code on what you want to give to customers. What's the point of this feature / improvement? Sometimes this takes a bit more deep thinking before diving into code, but it often leads to an update getting to customers faster in the long run because it avoids mid-stage pitfalls in the product development process.
• Get something to production as soon as it's better than what's already out there. Yes you can wait until it's 100% of what you intended it to be, but if 80% is already better than what customers can see today, then it likely deserves to go out now. And the next 20% can go out shortly after when it's ready.
• Debates about new functionality and UI ideas are rarely solved quickly through discussion internally. What usually leads to a clear decision and an agreement is cold hard facts, and real user feedback. The quicker you can put a real feature or updated interface in front of real users and ask them real questions and track real usage, the quicker you can make a decision to kill, improve, or completely change said feature.
• Avoid guess-athons. Watch this talk. Watch it now.

Ship often

I think it'd be fair to say we have the "ship early" part a lot more nailed down than the "ship often" part.

Frequently shipping code, updates and refinements takes real discipline.

"Shipping often" requires listening to your customers and taking their feedback seriously. It requires tracking feature usage and interactions in your product carefully. It requires ingesting a ton of data, and swirling it around with all the other factors in your brain, and making a call on what and how you improve the product. It's an art and a science and it requires military-like disciple to do properly in a product team.

• Ensure when a feature is shipped that the key interactions are tracked – either with an internal analytics tool, or with something off-the-shelf. You wouldn't believe how often teams get to a point where they want to redo a feature or interface, and only at that point realise they haven't got any usable data to back up their decisions.
• Get new features in front of users. Even if it's just another team member who's been less involved in the project at hand. Ideally get someone who's a long-term user AND another who's a complete novice, and see how their usage and

...And how to measure it.

It seems every piece of startup advice out there tells you to build something people need / want / love.

It's great advice, but I'm skeptical that many founders start businesses to build something people don't want.

Striving to build something people love is obviously a sensible idea, but how do you measure for that? How do you prove you're building something that's truly delighting users?

You can measure daily / weekly / monthly active users (DAU / WAU / MAU) but that just shows people are using your product. They don't necessarily love it.

One step further, you can charge for your product and see how much people are willing to pay for it. You can measure Average Revenue Per User (ARPU) but this is still a second-order result of someone loving your product. They may be begrudgingly paying for your service and actively seeking a replacement to get them out of the horror they're experiencing while dealing with your awful UI. Or they might be in love with your product and telling all their friends about how incredible your Super-Awesomizer-Filter feature is.

Talk to your users

The best way to truly understand whether you're building something people love is to ask them.

Sounds obvious, but it's still extremely rare that product focused people in software companies actually reach out and talk to their users. It seems people don't have time. But the value in talking to even one user is huge when compared to not speaking to any.

There are a few challenges, though, in asking hundreds or thousands of users what they think of your product:

• Unlike reporting on DAU, or ARPU, you won't have a complete data set. You'll only have a sample – some, if not most of your users won't respond to a survey or even a short email asking them for feedback.
• It's extremely difficult to turn thousands of emails into actionable information. You have tons of handy, interesting emails to read, but you have no way to measure whether people are happy or satisfied with what you're building. You have to translate their message into "loves us 😘" or "doesn't love us 😭".

Net Promoter Score (NPS)

The good news is there's a tried and tested method for measuring customer satisfaction – whether people love what you're building. It's called Net Promoter Score (NPS) and it was introduced in 2003 by Fred Reichheld in this Harvard Business Review article.

Whether you know it or not, you've almost certainly seen an NPS survey before. It's a simple question:

“How likely is it that you would recommend our company / product / service to a friend or colleague?”

You can then answer this question on a scale from 0 – 10 – with 10 being the highest accolade a user can give you. You can ask for more feedback beyond this – following up with a

“A good plan violently executed now, is better than a perfect plan next week.” – General George Patton

If there's one thing that's become clear to me over the years of running a startup, it's that you need to value people, decisions and actions that get stuff done.

There is certainly a lot of value in doing things “right” and striving for perfection in design and development and marketing and sales. But in the overwhelming majority of cases, an attitude and focus on “getting it done” almost always leads to a better outcome in the long run.

Getting something done means you can learn from it quicker and do it better next time round. Iterate faster. Learn faster. Improve faster.

Act now. Not tomorrow.

We've had a saying for a while at GoSquared – “Act now. Not tomorrow.” It started as a way of explaining our product – super easy to use, real-time analytics that your team will actually use. But it developed into more of an attitude that we work with across the team.

We've still got a way to go, but we try to, in as many cases as possible, take action sooner rather than later, even if there's a possibility of doing something better or smarter or cooler tomorrow.

Why not wait until tomorrow? Sure, what does a day matter? A few hours here and a few hours there. Who cares?

It turns out, hours add up. Hours add up to days. Days add up to weeks. As you multiply it out across the team, across multiple projects, weeks become months.

You end up spending months with code and designs and projects and conversations that just sit stale and lifeless. You spend months holding back new features and ideas from users. Of holding back questions from real insights.

You waste months, an hour at a time.

“If everything seems under control you're just not going fast enough.” – Mario Andretti, racing driver

Sometimes it can feel like pushing a new feature out today, or starting a new sales conversation this morning is just too soon. What if people try it and it breaks? What if things move quickly and they want to get going before we're ready?

When running a software company, there's very few things that aren't undo-able. You can hit CTRL+Z on almost every decision you make when you're a young, small, hungry tech startup.

That's why erring on the side of “do it now, worry about it later” often works far better than “worry now, prepare, and then do it later”. All the worry, all the planning, all the preparation is often worthless because that new feature will only be used by 10 customers, and that sales conversation is going to take 3 months before you get a commitment.

Find people that feel comfortable when things are moving fast. Set up processes that encourage quick decisions. Remove barriers to shipping features to customers.

I never used to care how many steps I walked in a day.

Since I've had an iPhone that tracks my steps, and more recently, an Apple Watch, I've become obsessed with the number of steps I do.

I have to do 10,000 steps a day.

Having known friends who've owned Fitbits for years, I understood 10,000 steps to be a healthy yet obtainable goal to aim for every day. aside from that, I don't fully know whether 10,000 is life changing compared to 9,000 or 11,000, but it's a line in the sand to aim for. That's become my goal every day, along with filling all the Activity rings on my Watch.

In fact, with the Watch, it's become more than just a habit – I can't stand the idea of getting 95% of the way to my goal but not hitting it. Often when I get home in the evening I'll walk out again just to make sure my goals are all achieved.

"It's hard to improve what you aren't measuring"

In just a year, I've gone from not knowing how much I walk, to obsessing over every step and reaching higher every week. I feel a healthier person for it, and importantly, I feel in control. I feel far more aware of my overall fitness, and what I need to do to improve.

I wonder, though, how much I'd be striving to walk that extra few steps, or take the long route to work, if I didn't have a number to aim for. Goals, even if they're arbitrary to some extent, can be a fantastic motivator, and a great way to test what your limits are.

It's not just fitness. Aiming to get a new feature deployed by the end of the week, or aiming to send 10 emails to existing customers by the end of the day, or aiming to aiming to spend under £5 at lunch – these are all goals that you can force yourself to aim for, and the result might be a whole lot better than if those goals weren't there at all. At least you'll have something to measure – did you achieve it or not?

Next time you're setting out to do something – whether it be a new feature to ship, a new sales technique to try, or even just going out for a walk – try giving yourself a goal and see if it makes you do it better.

In a startup, everything's a priority.

If everything's a priority then nothing's a priority.

Sometimes it can feel like there's an infinitely long list of Things To Do. It can feel like starting on that list is pointless because it'll never be done. You end up in a cycle of inaction. Or, you have so much to do you panic, you try to do everything. You get others on the team working on things for the wrong reasons, not because they'll have an impact.

How do you cut through the chaos and prioritise?

It starts deep. It starts with having a reason to exist. I'm trying to avoid sounding too "Silicon Valley"ish, but you need a North Star to hang everything off. And you need to believe in that North Star very strongly. When you know what yours is, then a lot of thinking and a lot of decisions become a lot easier.

What's your North Star?

If you don't have one, spend as long as you need to find it. Once you've found it, ask yourself: How can you get closer to it over the course of the year? How can you get closer to it over the course of the next week? The next day?

A few things to consider:

• Who are you fighting for?
• What is the technology or incumbent you are trying to replace? What do they stand for?
• What makes you different?
• Why are you the right people to tackle this?
• Why now?

Taking time out to have a plan

If you're a small team, it's easy to spend 100% of your time on the day-to-day. There's always a customer to respond to. Or a bug that needs to be squashed. Or a feature that needs to be shipped.

"Planning" is almost considered a swear word in startup land.

But when was the last time you spent a solid day planning your future? Do you have a plan? Do you know who your next 3 hires will be? Do you know when you'll make them? Do you have an expectation for revenue growth over the next 3 months? Do you know what will impact it? Do you have a well prioritised backlog of things to work on beyond the next 2 weeks?

Sometimes you need to take time out to plan. Don't spend weeks. You probably don't even need days. But you do need a plan.

OKRs

Objectives and Key Results are a great way to align the team around a few important things over the course of a quarter. The framework seems to work pretty well for Google, who have been using the concept for many years, along with a thousands of other companies all around the world.

If you're looking to try out OKRs in your startup, here's a few things to help:

• Make them visible to everyone.

Have a look at your phone. How many of the apps on your home screen are primarily for consuming content? How many are for producing content?

Have a look at your schedule this weekend. Have a real good look. How many hours of your weekend were spent consuming (content, food, beer, you name it)? How many hours were spent producing content?

Everyone needs their downtime.

But the default in society is not to produce. It's to consume. The default is to watch every episode of Game of Thrones. Every episode of every new show. To not miss out. The default is to catch up on your Facebook feed. To get rid of the red badge on the Twitter icon. To read every message that hits the inbox.

When you've done all the consuming you need to do, is it any surprise there's no time left for producing?

Making more time for producing

I've struggled with this challenge for a long time, but I feel I'm producing more work, and better work than I have in years.

What I'm doing differently:

• Replacing the "consumer" apps on my home screen with "producer" apps – apps for writing, for drawing, for sharing.
• I never interrupt my day to read an article. It gets saved to Instapaper for reading at a convenient time.
• I use Instapaper's "Speak" feature to read out articles while I'm commuting and walking. So I save my eyes and my time.
• I'm setting myself a small but significant goal of writing once a week. It doesn't necessarily get published but it gets written.
• I almost never check my Twitter timeline. I am not up to date to the second on every single tiny message that everyone on the Internet shares, but I'm ok with that. Instead, the very most important news is pushed to me from the BBC News app, and the most shared articles on Twitter make their way to me via Digg's "Digg Deeper" feature that gives me a list of the top shared links from all the people I follow on Twitter.
• It's not to everyone's taste, but I've found the Apple Watch to be a big influencer on my habits – I no longer get distracted when I get an email or a notification. I just glance at my wrist and then carry on with my day. My old routine involved checking one app, then checking all the other apps that have a red badge on them. And then inevitably reading my Twitter timeline.
• As a team we've been getting smarter about our use of Slack so we each get notified about the information that's most relevant, and can tune out of less relevant updates.

A quote I read a while ago that's really stuck with me (unfortunately I can't find who originally said it):

"No matter how much time

It's a subtle difference, but "reporting" and "measuring" mean quite different things to me.

It feels like "measuring" is far more actionable. When you measure your sofa you know if it will fit in your living room. You don't report on your sofa dimensions to a third party for approval.

Reporting seems inherently generic. Measuring immediately ties the action to the "what" – what are you measuring? What are you measuring against?

Nobody measures for the sake of it – there's always a reason or a need. People produce reports on meaningless numbers all the time. Reports don't always have conclusions.

At the end of the week do you want to produce a report on a bunch of numbers, or do you want to measure your progress against your aims as a business?

Next time you're looking at metrics for your business, ask yourself if you're merely reporting them, or measuring something.

Talking to customers can feel like getting punched in the face.

Yesterday I watched a great TED talk – "the single biggest reason why startups succeed" by Bill Gross. One of the best lines was his quote from boxer Mike Tyson that forms the title of this post. It made me think about our current process at GoSquared to focus us on building the right things.

You spend days, weeks, maybe even months with an idea, building it into reality, only to put it in front of your customers and realise it's off the mark with what they really need.

The sooner you can turn your idea into something tangible that you can show your customers the better. That doesn't mean building the thing, it doesn't mean building an "MVP", it can be as small as having a conversation face-to-face with just one customer.

Here's how I'm trying to avoid getting punched in the face:

First, by talking to the customers we want. Meticulously noting down their business, where they're at (are they growing? Are they struggling against their competitors? Are they on their way out of business?), what their job is within the company (not just their title but what they actually do all day), and the tools and processes they currently use to get their job done.

Then we take that away and look at how we can help – both with our current features, and with what we might build in the future. This conversation helps focus our current pitch, and inform our future roadmap.

For features we haven't yet built, I try to avoid describing in words what we are working on. I much prefer to show something visual. Not a fully working app or flow, but mockups. With a copy of Sketch and a prototyping tool like Marvel App or Invision, there's no need to waste time on HTML or CSS before getting feedback. You can get your ideas in front of a customer in hours.

The best bit is the feedback – does the customer even bother to respond? Perhaps this isn't a big enough problem for them to care about it. Perhaps they're just busy. Do they hate what you've sent them? Great! You've just saved weeks of building the wrong thing. It's even better if they like it. But will they pay for it? Do you need to build it to find out? It's amazing how motivated the team can feel when working on a feature knowing there's already a queue of customers waiting for it.

Avoid getting punched in the face – don't write a line of code. Don't wait. Talk to customers, mock up your idea. Set a deadline for yourself. Send what you've mocked up to your customers. Get their feedback. Act on their feedback. Rinse and repeat.

As a founder you wear a lot of hats. Sometimes the jobs you have to do are not always evident to the whole team.

Jobs like deciding on a name for a new project, deciding on the next project to focus on, deciding on who to hire next. Often with these jobs, the team don't see anything until they're complete, and the result is often as small as a single sentence, perhaps even just a single word.

Unlike those who are full-time developers, or full-time designers, or sales people, as a founder some of your toughest work – some of the jobs that require the most time and energy from you – can be almost entirely invisible to the rest of the team.

Just as an iceberg is almost entirely invisible to a boat on the surface, your team likely only see the tip of most of the "admin" work you do – the decisions that come from hours, days or weeks of thinking, planning and sketching.

What makes invisible work difficult to communicate is it's often not terribly clear how close to completion it is. Unlike designing a web page, or working on a sale, showing your progress on tasks like deciding on a new direction for the company, or figuring out your next major feature can often be impossible until they're 100% complete.

My one suggestion would be this – write it down. Even if you have nothing to show for your progress, write down your thoughts and feelings at the end of the day based on your findings towards the task at hand. Even better, run those thoughts by a colleague or co-founder.

Some of the hardest work you do as a founder is invisible until it's complete. Finding a way to quantify it and get feedback on it can help make that work more visible. It seems the more visible you make the task the closer it gets to completion.

"Saturday Night Live doesn't go out because it's ready. It goes out because it's 11:30."

I recently listened to a fantastic episode of one of my current favourite podcasts – The Growth Show by Mike Volpe, CMO of Hubspot. The episode that got my creative juices flowing was where Mike chatted with Seth Godin – the God of marketing, and an inspiration of mine for years. In the episode, Mike asked Seth how we manages to produce so much content on a daily basis. Seth suggested that you should set yourself a schedule (e.g. write every day for a month) and see how it goes.

I felt inspired. "Write more. Write more!" I said to myself.

But very quickly I ran into a perhaps silly roadblock – what if I start writing now and realise 3 months down the line that I'm writing in the wrong place? Shouldn't I make sure I'm writing in the right place before I embark on this journey?

Should I really invest all this time writing on a platform that I don't own?

I suppose I had better decide on the right blogging platform.

Medium

I already have a Medium blog (can you call it a blog?) – it currently has two posts. Two posts, but two of my best pieces of writing nonetheless – an illustrated essay on why we redesigned GoSquared, and an extensive piece contemplating why Apple would make a watch.

Medium is probably the most thoughtfully designed destination to write content on the web. It has perhaps the closest thing to a perfect text editor I've ever used – I prefer writing on Medium to using any native text editor I have on my Mac. The care they put in to both the writing and reading experience is astonishing – have you noticed the underlines?

Medium is reassuring to the reader – I know whenever someone tweets a link to a piece with a Medium URL it's going to be easy to read, it's highly likely to be well written and considered, and I know I won't be met with a horrible popup modal asking for my email address the moment the page has loaded.

My biggest issue with Medium, though, is it's not mine. I love reading articles on Medium, but whenever I come to telling friends or colleagues about a piece I read last week I almost always end up explaining it as "a great piece I read on Medium" rather than "a great piece by The Writer Of Said Piece". That's a concern for me – I don't particularly want my own voice and my name to sink into obscurity while I put my time and effort into writing articles that build the name and brand of what is essentially a large magazine that doesn't pay me to do so.

Tumblr

I've had a Tumblr blog for as long as I