“Vibe coding” is a category error

The phrase “vibe coding” has bothered me for some time.

It’s usually said with a smirk. Usually by experienced engineers.

And that was appropriate for a while. 2024-25 were full of crypto-bro levels of fanfare fuelled by big egos building small apps in days.

Most of that was hype was unwarranted.

But we're in 2026 now. The slow boil has reached us.

What is now possible with AI has evolved unimaginably.

We've moved past "vibes", yet the term “vibe coding” has stuck.

Empowerment isn't a "vibe"

To many, the term implies that what’s happening is casual. Loose. A founder waving at an LLM and hoping something compiles.

But “vibe” massively undersells what’s really going on.

For someone like me — not an engineer by training — being able to build working software isn’t about vibes. It’s about empowerment, velocity, momentum. It’s about user experience. It’s about customers and satisfaction.

Your product is a conversation with the market.

I first heard this quote from Des Traynor on the Cheeky Pint podcast with John Collison and it’s really stuck with me.

For years, the path from idea to implementation looked something like this:

Have an idea → explain it → write a spec → justify it → debate it → prioritise it → design it → refine it → debate it more → build it → test it → ship it → get feedback → repeat back to step 1.

Every step added latency. Not just time — cognitive drag. Social drag. Justification drag.

Not to mention, the very number of steps, the time consumed by passing through all these steps, and the very thought of even going through these steps, meant many ideas were never even attempted.

It may sound harsh, but I've seen it in so many teams: engineering is where good ideas go to die.

Now? If you're set up to embrace the world we're in, the journey is radically transformed:

Idea → build → test → refine → ship → improve.

And that is not a cycle that happens in months, weeks, or even days. It's a cycle that can happen in hours, if not minutes.

Speed of iteration isn’t a "vibe"

Forgive me for linking to another Stripe founder, but I have long found Patrick Collison's "Fast" page immensely inspiring: examples of people quickly accomplishing ambitious things together.

Iteration speed is leverage.

When building something new, the most valuable thing is rarely elegant code, a beautiful user interface, or following a set process or doing things in a certain way.

It’s really simple: all you really care about, to begin with, is whether the thing you are building is actually valuable.

Does this flow make sense?

Is this interaction clear?

Does this feature solve the actual problem the user has?

Before, for any product manager or designer or non-technical founder, exploring those questions meant being away from the product.

Drawing, writing, designing. You would do a lot of work in places that were not the actual

Friday finds #3 — tools and links for your weekend

I hope you enjoy these, too, and if you have found (or made!) anything decent lately, please let me know.

Worse on Purpose: a site that keeps track of famous brands (and their owners) and whether they're still worth it or have declined in quality (also see enshittification).
Flowstate is a service that transforms handwritten notes into digital formats that can be used in the tools you already use.
Want to become a little more resilient and self-sufficient? Want to prepare for Doomsday? Here's a Swiss government website that shows you exactly what to get, in what quantities, depending on the size of your household and how long you want to survive for.
Uplock is a lovely native iOS and Mac app for securely saving everything but your passwords — think passports, ID cards, private documents, and more.
Want to own Stanley Kubrick's directors chair? It's going up for auction along with a few other collectors pieces soon.

Enjoy the weekend!

Use the goddamn product

Being customer obsessed is easy to say, but extremely hard to consistently do.

Whether you run a five star hotel or a SaaS business, the best way to understand how to make your product or service better is to experience it as a customer would.

Yes, it's crucial to gather customer feedback, to actively seek their feedback, and to execute on improvements based on what they tell you.

And as a software business you can instrument your app with metrics and tracking so you have every datapoint you could ever dream of.

But I'm convinced that customer feedback and metrics can only take you so far. No matter how direct and open your customers are with you, they likely will never tell you everything that could make your offering better.

And, the act of responding to customer feedback inherently means building something and waiting for feedback to improve.

You can make your offering better without a single piece of user feedback by doing something simple: use your service yourself.

For a software business, you should sign up for your own product. And you should use it on a regular basis.

And I don't mean "use" it in the sense of testing. Of course you want to make sure a few common workflows always work. I mean really use it like a user would — to carry out an objective, under realistic conditions.

In EcoSend, we've fixed hundreds of things that users have never (and I suspect would never have) told us about. Does that mean those issues don't matter? I believe they do — they all add up to an experience, whether vocalised or not. They're not show-stopping issues, and they're not necessarily bugs. They're quirks, things that could be more obvious, flows where we can save the user a click, or guardrails that help the user avoid a mistake.

I love making these kinds of improvements — they often go unnoticed, but they add up to an experience that feels more robust and reassuring, and at times delightful.

It's this approach that leads to good software. No matter how much AI is used in software creation, the process of using your own product cannot be outsourced.

The best software will always come from countless iterations based on feedback and refinement. When you are a user, you can run so many more of these cycles without users ever needing to tell you.

Friday finds — tools and links for your weekend

Following on from last week's "tools and links" post which some of you really enjoyed, I thought I'd do another one this week.

As you might know, I am a bit of a geek. I love finding new tools, gadgets, and things on the internet.

I hope you enjoy these, too, and if you have found (or made!) anything decent lately, please let me know.

“The computer will allow man to return to the Hellenic concept of leisure”. A wonderful site dedicated to past predictions of how key technologies will transform society. The Techno-optimism archive.
Bookpile takes an ISBN and tells you which bookshops, chains and libraries near you could be asked for a copy.
Trackables turns the data your Apple Watch already collects — activity, sleep, steps, heart rate — into a clear, friendly, transparent interface. Found this via Gruber — it's free of charge, private, and made by a small team of ex-Apple folks.
whoami.wiki looks like Wikipedia but if it was focused around your life. It's a system that turns your digital archives of photos, chats, documents, location history, and different types of data into a living encyclopaedia about your life. Not sure on the background of this and haven't tried it but it seems like a very interesting project.
Moment is a timer I've been using lately to help me stay focused. It puts your wellbeing first with Apple Health integration (it asks how you feel after a focus session) and provides on-device insights.

Enjoy the weekend!

Revisiting the agile manifesto in the age of AI

If you’re an engineer I can already hear you letting out a sigh.

As long as I’ve been in the world of building software I’ve heard the term “agile” and I’ve never really dug into it too much.

It’s always had connotations of “work” and project management and, to be honest, Jira.

Yuck!

It was only recently when someone shoved the core principles of the Agile Manifesto under my nose that I thought to take a closer look.

If you haven’t come across the Agile Manifesto before, you can find it on a website that appears to be unchanged since the 90s. It’s gloriously old school.

But the words are as relevant as ever. If anything they feel more relevant and important.

For convenience, here are the principles, with a little interpretation of my own.

Satisfy the customer

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Satisfy the customer. Satisfy the customer.

If nothing else, this is the most important principle of all. If this was the only principle, and every single organisation and individual adopted it, I think software would be perceived in a much more positive light by people. And I think we would perhaps have a lot less, but better, software.

Embrace change

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Changing your mind when new information emerges is a good thing.

Working software in weeks

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

I'd argue this should now be hours, or days, in the age of AI.

Don't ignore the business

Business people and developers must work together daily throughout the project.

By "business" people I'd include customer service, marketing, sales, and leadership.

Trust motivated people

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Speak to each other

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Technically Google Meet and Zoom are face to face. But nothing beats being in person.

Actual working software is the priority

Working software is the primary measure of progress.

Yes you can get a fancy dashboard to measure user numbers, activity, and more. In fact, I am inclined to believe analytics can be very helpful! But don't lose sight of the top priority: working software.

In an age of tokenmaxxing, and having witnessed previous phases of optimising for "lines of code written", this feels like a rather important goal to keep in mind.

Sustainable development is sustainable

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

You can only move fast and break things

Focus means saying no

Ask anyone who's been in business for a while how they got successful, and they'll almost always highlight the importance of focus.

In the famous Apple video called "Intention" that opened one of Tim Cook's first keynotes as CEO — there was the unforgettable line:

There are a thousand no's for every yes.

And as Jony Ive has said many times: people think focus is about saying yes to one thing. In reality, it's about saying no to (sacrificing) many fantastically good ideas. All so you can focus on the one thing that really matters most.

That all sounds rather obvious, perhaps.

But of course, that is all a lot easier to accomplish if you're incredibly sure of what you should focus on.

The challenge, I have often found, is choosing what to focus on.

What is actually most important? And can those other ideas, asks, and requests really be a "no" right now?

Surely there is a balance?

The more you can gain conviction on what is truly important — what truly deserves your time and attention — the more confidently and therefore successfully you can focus.

And with that focus — only with that focus — can greatness be achieved.

Some more tools and links

I am an eternal geek and I love finding new tools, gadgets, and things on the internet. I hope you enjoy these, too. If you do let me know!

Blankie — ambient sounds to help you focus and get into your flow state. Beautifully designed native app for iOS and Mac.
Coop — an app and network that makes it easy for you to buy goods (like bread, plants, and other food) from those nearby. Seems to only be in the US right now, but this seems like the sort of thing we need more of in today's over-commercialised world of "bigger is better". No: smaller is better!
AppZapper — the return of a classic Mac app. Super nerdy but so fun. It's literally just an app for deleting apps on your Mac. But you use a laser gun to delete them. Proof that software doesn't need to be boring.
Clop — a handy Mac app that automatically optimises images and other files you copy to your clipboard. Just like how EcoSend optimises images in your emails, this does it for you on anything you've got on your Mac, even PDFs. And does it all locally so there are no privacy concerns at all.
RecipeTables — I can't believe I have reached this age and only just discovered this ingenious way to present recipes. A tabular form that makes it easy to see all ingredients, all of the steps, and the order you prepare them in, for a recipe. Data visualisation and the engineering mindset at its best.

Seen anything cool lately? Found a tool you simply can't live without? Let me know!

Your product is a conversation with the market

Des Traynor and John Collison on Stripe's Cheeky Pint podcast

A while back I watched this talk from two legends of the software world: Des Traynor of Intercom and John Collison of Stripe.

I love these discussions and this series I find to be a relaxing, fun environment. How could you not enjoy watching a couple of smart people sharing a Guinness or two, discussing topics you've always wanted to ask them about?

A few quotes that really stuck with me:

A product is a conversation with the market.

Your launch is your opening bit, and then you have to basically adapt and react to what gets thrown back at you, which might drag you in different directions. And then you need to have, again, the confidence to prune certain things.

People massively underestimate what it means to have a truly happy customer base.

Word of mouth doesn’t have a UTM code.

Don’t afford yourself too much freedom on pricing. You will end up crippling yourself in a quagmire of complexity.

The whole discussion is worth a watch or a listen.

And it's worth noting that since this aired, the company Des co-founded, Intercom (and Fin) sold to Salesforce for $3.6 billion.

Why individuals have an incredible advantage over teams when building software

If you want to go fast, go alone. If you want to go far, go together.

I’ve written about building software (primarily web-based software for small businesses) many times in the past.

It’s pretty much the only thing I’ve ever done.

There has been more change in the last two years than the last twenty combined.

Thanks to AI, the processes and methods and tools have changed unimaginably, and continue to do so.

But what amazes me is that many people — and many businesses — have barely changed at all.

Both in small teams and large ones, I still hear timeframes quoted in months for building features that could be crafted in days.

It’s easy to think everyone is on the cutting edge if you’re someone who enjoys checking the latest releases of each model, seeing what the Hacker News community have to say about every new AI developer tool, or have spent any time building things with AI recently.

But most of the world isn’t yet doing that.

Most people work in teams and many work in teams at bigger businesses. From what I’ve seen, the structures in place at most larger businesses are largely incompatible with — or at least are limiting — how they can truly embrace AI to build software.

The current (old) way

The old way of building software often meant doing something along the lines of the following:

Talk to users.
Digest their feedback and figure out what to build.
Design a prototype (often a wireframe).
Hand over a written document and a wireframe to developers to build out.
Do some more design to polish up what the developers have built.
Get the thing deployed and live on a server somewhere.
Go back to your users and see how they like it.
Depending on what the users say, go back to step 2 and repeat.

Every step of that journey could take hours if not days… if not weeks.

In an early-stage startup, that is time you don’t have. One of the most critical processes to speed up is that loop of feedback > build > ship.

But when the steps in between can take hours or days. Communicating and translating ideas into actual built products is extremely hard. Yes it may take a week to deploy a new database but have we accounted for the days of discussion between product and engineering to make sure its clear why we need that database and what it should do and what it’s strengths and weaknesses are and how much it’ll cost?

The advantage of the individual

I think individuals have a tremendous advantage right now because they don’t need buy-in and they don’t need to agree with anyone but themselves.

You could also see that as a disadvantage. Sometimes you need to be told no. But more often than not, you need the market to tell you that, not the developer.

I'm

Don’t devalue instinct

Being data driven is an extremely prevalent theme in the tech world.

Everyone wants to use data to make better decisions, and ensure they’re not being stupid.

But in the rush to be data-driven, it seems many people and many teams frown upon instinct as a method for making decisions.

The smaller you are, and the earlier you are, the more you need to rely on your gut.

As you grow, you gain the privilege of more users, more customers, more feedback, and more data.

Instinct and intuition is a form of data, and I’m convinced that we are still in the early innings of understanding how best to apply it to decision making.

When should you separate “growth” and “product” in a startup?

In the summer we removed any concept of a “growth” and “product” department at EcoSend.

I should say “department” is a loose term. We aren’t a big team (less than 10 people) so the terms mostly applied to meetings, and areas in our tools like Slack for chat and Linear for project management.

The distinction between the two was starting to cause more issues than it was solving.

The problem with separation

I found myself asking questions daily:

Is this a growth thing?
Is this a product thing?

Those questions can be helpful in a larger team.

But at our size, the primary thing I care about is: What will this do for the business? How will this make things better for our customers?

And often the answers to those questions don’t naturally fall into one bucket or the other.

What’s a product thing if it’s not about growth, for a team of our size?

How do you classify and prioritise a product feature that’s designed to help us grow? Like a viral loop or a public facing design change?

With the two concepts labelled separately, a lot of the most valuable work fell through the cracks.

Almost everything one could label “Product Led Growth” (PLG) was in the middle. And it rarely got done!

We needed to change, and thankfully as a small team, changes like this don’t have to be a big deal.

The results so far

We removed the distinction over the summer and it went far more smoothly than I expected.

What we’ve shipped since this change:

These are the real results.

But I’m just as excited about the underlying changes, behind the scenes.

As a team we are now prioritising as one. One list, with a focus on impact.

We are uncovering problems that used to get passed around — yes even in a small team — and actually discussing them and finding a solution.

When coming up with ideas or reporting a problem, there was an overhead on every addition to Linear: where do I put this?

Now it’s all in one place. The prioritisation and decision is separate, and weighed up against everything, not an isolated set of priorities in one part of the business.

Some of this likely sounds obvious.

Or maybe you’re reading this thinking “hah! There’s no way that will scale!”

You’d be right to have either of those opinions.

Yes it’s quite obvious for us, but obvious solutions can stare me in the face for months before I try them. And often the change is not as bad as my worst fears.

I don’t believe this would scale to a team even with 10 people. But as I’ve noted in the past, referencing the wonderful Joel Gasgoine of Buffer: there’s an optimum level of process for any company. And too much,

It just works

There’s a saying, much popularised by Apple, that distinguishes certain products:

"It just works."

It seems like a very low bar on the surface, doesn’t it?

Surely every product works, to some extent.

“It just works” only becomes a selling point when you consider how much hassle most products are to use.

Remember the last time you bought anything significant — was it entirely effortless? Was it a pleasure? Was it obvious at every step what you needed to do to start getting value from it?

I think this concept applies to services and experiences as well as products. I've written before about the experience of using my gym for the first time. And there are plenty of restaurants and hotels I've been to that fall short of the mark when judging them by the "it just works" assessment.

I don’t believe these are exhaustive, but here are a few principles that come to mind for building a product or service that just works:

“It just works” means a lack of cruft and complexity.
"It just works" means the product is reliable and consistently so over its lifetime.
“It just works” means the maker has an opinion.
“It just works” cuts to the chase, and gets the user to their desired outcome as quickly as possible.
“It just works” eschews end-user choice for simplicity and obviousness.
“It just works” means prioritising the primary function of the product above all else, even if that is at the expense of other meaningful uses.

These are easy to write, but very hard to achieve in a team building a real product.

It begs the question, then, why do so many products and services not “just work”?

I believe most products on the market exhibit some combination of the following:

A lack of care. The designers and makers just don’t care enough about the end user.
There is a misunderstanding of the core purpose of the product.
Feature creep. In a drive to make the product more attractive to more people, extra features are added in.
Short-term financial incentives drive cost-cutting and profit over product quality.

There are too many products that fall short of the "it just works" goal. Fortunately, that leaves tremendous opportunity for makers willing to go the extra mile.

A few products I’ve used recently that just work:

Granola — we’ve all been on a Zoom call that has had some form of AI note taker unexpectedly join. We’ve all experienced how useless a transcription can be. And we’ve all tried taking notes from a meeting only to find we either weren’t paying attention or missed a critical piece of information. Granola is the first note taker I’ve found that truly “just works”. You install it on your Mac, there are no awkward bots, and the results I've seen have been exactly what I wanted. It just works!
The Journal app — one of

The joy of creation

Lately I have been conflicted in where I spend my time.

I love creating things. But I also love building a team, leading, marketing, and selling.

There have been patches of time where I have done very little creation, and in those periods I realise I quickly become demoralised.

I find joy in creation.

For as long as I can remember, I have been in awe of the idea that anyone can grab a computer, connect it to the internet, and build something. And that someone else on the other side of the world can then utilise and benefit from that thing.

Anyone can create something of value, and you don't need to ask anyone else for permission.

Creating vs publishing

I don't just like creating, I like publishing.

Don't get me wrong, publishing can induce immense fear.

But I get a kick out of directly creating something and then putting it live.

Getting feedback is addictive — whether it's seeing usage, receiving comments, or simply knowing "it's out there".

I sense that the act of creating is never complete, but publishing (or shipping) is a marker to say: I've completed the first step.

"Publishing" can mean anything here — deploying to production, putting a blog post live, hitting send on a Tweet or Thread, or even just writing an idea down and sharing it with your team.

The critical benefit of "publishing" is that you not only get to call your work "done" for now, you get to receive at least a little feedback: did anyone care?

Speed vs perfection

There's a study I read a while back in the book Art and Fear that summarises the dichotomy of aiming for perfection:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an “A”.

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

Ever since I read this, it changed my views on perfection.

"Quick and scrappy" is often viewed as "not the proper way". The proper way is to do X and Y and

Thready or not, here I come

As you’ve probably seen, Meta launched their newest app today, Threads.

It’s like Twitter, only considerably slimmed down.

For day one, it seems it couldn’t have gone better for the makers of Instagram.

As someone who geeks out on tech products all the time, I find the Threads launch fascinating, so I jotted a few notes and observations down about it.

Timing is everything

It’s no coincidence that Threads is launching in the same week that sentiment towards Twitter is at an all-time low.

Elon Musk decided to enforce aggressive rate limiting for all users, made Tweeetdeck redundant for many, and obliterated the value of public URLs by preventing tweet embeds for non-logged-in users.

It’s clear Threads could be better.

It could have more features.

It’s not quite ready when you compare the feature checklist.

But launching this week while Twitter is in the dumps (more than usual) may just give it the strong gust of goodwill that helps this spark of a product turn into a full-blown, roaring fire of a platform.

Ship early, iterate

Many “critical” features aren’t in at launch, but is the app and experience solid? Is it easy for new users to onboard? Is the experience reaching a threshold that the majority of users will enjoy and trust? Yes.

You want the ability to filter your feed, you want better search, you want to have more clarity on who’s following you. You want an API. You want the app if you’re in the EU!

But all of those are trade-offs between shipping now or shipping later.

Someone had to make that call. The easy option is always to wait. Waiting always feels safer.

Shipping this week looks like it was the right call. The rest can come later.

Aside: If you’re interested, a while ago I wrote about the importance of shipping early, and often.

Nothing to lose

What I’ve enjoyed most so far as an observer of the Threads launch today has been seeing Meta operate like they have nothing to lose.

Launch today. Move fast. Share the numbers. Integrate with the open standards (eventually).

It seems unlike many of Meta’s most significant big launches: Instagram Stories was a bolt-on to not lose out to Snapchat, Reels is another tab to avoid losing out to TikTok, and Instagram itself was an acquisition.

Threads, though, is a joy to see: Zuck and the team building something that doesn’t just compete, but that could genuinely be better than Twitter. Making something people want. With a beautiful blank slate.

Maybe I am just relieved to not have another tab, view, or swipe in the Instagram app. Or perhaps it’s that my trust in Twitter has dwindled.

Whatever the reason, I’m rooting for Threads. If you’re on it, join me!

Sign up for your own product

"You don't get a second chance to make a first impression."

If you work at a gym, you know where the changing rooms are.

If you’re joining a gym for the first time, and you’re heading in for your first session, everything is alien.

You don’t know where the changing rooms are, and if the signs don’t point you in the right direction, you’re lost.

When I signed up for a gym session recently, I felt totally lost and a little foolish, wandering around trying to find somewhere to get changed into my kit. I almost left out of sheer embarrassment before I plucked up the courage to return to the reception desk and ask.

Whether you build software, build physical products, own a restaurant, or run a gym, nothing beats using your service as a first-time user to find out how you can improve it.

It’s always great to get feedback from customers but sometimes they don’t tell you everything. Sometimes they may not even care as much as you do about the experience.

It’s easy to even get frustrated that customers don’t “get” the thing you’ve built. You’re so proud of certain elements you can easily get blinded from the areas you’ve overlooked.

A while ago, I gave a talk on user onboarding, and one of the recommendations was to sign up for your own product every week. I even paused to encourage the audience to put a recurring event in their calendars!

Several years on, I feel that suggestion is as relevant as ever, and it’s advice that’s easy for me to give and seemingly hard to follow.

When did you last sign up for your own product?

Why would Apple make a VR headset?

A quick sketch of my dream Apple headset

The silence is deafening — Apple is going to announce a VR headset imminently.

The very fact Apple hasn’t denied any rumours, and the increasing nods towards a big launch, are evidence enough. If they weren’t, then we’d know by now.

The feeling is very reminiscent of the run-up to the launch of both the original iPhone and Apple Watch — both products were widely expected to be unveiled, but the knowledge of exactly what they would entail was almost entirely unknown.

We’ve been here before

My sketches of the proposed Apple Watch ahead of its announcement.

While I never wrote about that feeling before the iPhone launch, I wrote a piece just before the Apple Watch was announced: “Why would Apple make a Watch?” in which I tried to get into the mind of the decision makers at Apple and understand why they would enter the watch market and what the device might enable.

Looking back at that piece, I feel quite proud. While I was not the only person pondering such concepts, I proposed the Apple Watch (or iWatch as I believed it’d be called at the time!) would:

Enable you to pay on the Subway, and allow for contactless payments — before Apple Pay came along.
Have easily detachable / swappable straps.
Become a key health companion, continuously monitoring your activity and heart rate.
Enable you to sleep better and wake up at the optimum time.
It’d prioritise telling the time at all costs, despite its smart features.

I got many things wrong too — I thought the Watch would:

Have incredible, unbelievable battery technology.
Rethink the concept of a display: “I will eat my metaphorical hat if we see a full colour backlit Retina display on the device”.
Be the “magic wand” remote to your Apple TV.
As you can see from my sketches — the physical appearance of the Watch I believed Apple would make was more akin to a Fitbit activity band.

I love reflecting on that post because it’s what makes following a secretive company like Apple so fun — you can dream and imagine, and you get to find out eventually if you were right. You get to decide if you felt Apple lived up to, exceeded, or missed your expectations.

So with an entirely new device and category just around the corner, what do we hope to see from the Californian giant?

Let’s dig in…

What will it be called?

I don’t believe Apple will call this a “headset” at all. Apple has never referred to the iPhone as a “handset” even though it’s how carriers and many consumers referred to phones before the iPhone.

Normal people don’t buy “headsets”. Headsets are for gamers and geeks.

Apple makes products for people who want the best, and they, of course, charge prices aligned with that approach.

There are numerous rumours and trademark filings, and even supposed confirmations in various

Episode 8 of Lost and Founder — How soon should you launch?

This week we just launched a new product at GoSquared: Lead Forms.

Launches are always exciting, and every time we do a launch we learn from it, so I decided to focus this episode of Lost and Founder on the topic of launching.

As I’ve written in the past, I feel launching is a bit like inviting your friends or relatives over to your house. Inviting someone over forces you to get your house in order — to tidy, to prepare for a deadline, and to prioritise unfinished tasks.

When launching a product or a feature, or even launching a whole new business, it’s often difficult to know when to do it. You’re pretty much always going to launch too early or too late — from my experience, it’s almost impossible to launch “perfectly on time”.

If you’re getting ready to launch something, I hope this episode is helpful for you.

Actions / take aways

I’ve outlined some key actions and take-aways for those too busy to listen to the full thing:

Set a deadline for your launch — every time you do this you learn how to get better at setting deadlines.
Assign an owner if you're in a team — if more than one person “owns” a project, then no one actually owns it.
Be clear on your priorities — ensure everyone is aware of what is most important to the launch and the company.
If in doubt, optimise for speed — moving faster tends to solve more problems than it creates. Speed means you learn faster.

Links and further reading

If you haven't already, it'd mean the world to me if you subscribe to Lost and Founder wherever you get your podcasts — find all the links to subscribe here.

Thanks and see you next time!

Launching is like inviting your friends over

For the last year, very few of us have had the chance to have anyone over to our homes, but I was recently casting my mind back to those happier times, and I made a connection in my mind.

I am not sure about you, but in our house, whenever we invite someone over, it’s always a deadline – a fixed point in time to get our house presentable.

I am not saying my house is a mess, but when people come over I want to present the best version of myself and my house to my guests. And when we don’t have guests, sometimes those standards can slip a little. The handful of cups on the kitchen counter. The stack of 5 letters on the kitchen table. The extra pair of shoes left out in the hall.

Having people over pushes me to tidy all these little things up – to wash the cups, to sort the letters, to hide the shoes.

In my mind, that’s exactly what launching / shipping does: you may not be ready, but you have to get your product or feature presentable – ready for others to experience it. It focuses you.

Who care where the shoes go, or whether the cups are in the dishwasher or hidden in the sink. What matters is the place looks good and feels warm and welcoming.

When shipping – who cares if the extra settings option can’t make the cut, or the secondary heading on that alert modal isn’t precisely following the style guide. What matters more than anything is you hit the launch date and ship.

Having a deadline (like knowing a friend is coming to visit) forces you to tidy, focuses you, and restricts you from tackling anything too ambitious. External judgement and validation can be a powerful motivator to prioritise.

Talk it through

When was the last time you talked someone through your product or website?

Try it now. Try talking through – even to yourself – how to do a specific action in your product.

Hard, isn't it?

I find this to be one of the best ways to quickly get a feel for usability problems, and to discover opportunities to make our products better.

If you can't talk it through simply, you probably haven’t simplified it enough.