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 to focus and say no to things, and

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 interactions differ.
• The longer you leave a feature or UI element, the less likely you'll be to go near it again to improve

...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 question on why the user gave the number they did naturally forces a more insightful answer.

At this point you might be wondering why

“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. Don't punish people for moving fast and breaking things.

Act now. Not tomorrow.

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. On a big screen, emailed out at the start of every week, stuck on a post-it note on your screen,

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 you spend watching TV, watch less."

We all have time to learn. We all have 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 can remember. I've never really known how to classify Tumblr – is it really a blogging platform?