#21. Good enough
#21. Good enough
plus The Perils of Prudence, Julian Shapiro, The Witcher, Jamie's vegetable lasagne
Hello!
Today’s post comes from a pub rant about product with my friend Ant . He surprised me by asking me to come into Accurx and re-rant but this time with their product managers, designers and researchers too. It was so much fun that I thought I’d share here with you as well.
Also it’s 22 years today since I got together with Esther. Happy anniversary us!
Good enough
One of the stark things I’ve learned over the last nine months is how different things are at a violently early-stage startup like CastRooms than in bigger organisations.
What’s jarring is that so much public wisdom around research, design, marketing, development and data doesn’t work well at our early stage. Forget having product-market fit - we are still pre-customer! So Twitter, blogs, books and podcasts leave me feeling lesser-than because I’m so clearly out of step with my peers.
I’m slowly finding early stage wisdom - guests on Lenny’s podcast talk about ‘zero-to-one’, Kent Beck talks about Explore, Simon Wardley talks about Explorers. But it’s rare.
My own shaky early-stage wisdom comes from Local Welcome and CastRooms. What strikes me is just how much there is to do (everything!), how few people there are to do it (4-6), and how little time there is before the money runs out (months not years).
The best response I’ve found is ‘good enough’ across the board.
But ‘good enough’ does NOT actually ever feel like ‘good enough’! This is non-obvious until you live it. The actual feeling is more like ‘this is appalling and I’m embarrassed to show my peers because they’ll laugh at how terrible I am on all levels’.
So today I’m talking about what ‘good enough’ decisions look like at CastRooms, how they often make me feel embarrassed, and why I’m mostly OK with that.
Let’s start with user research. We didn’t test any of our designs with users for six months at CastRooms. I’m a former lead user researcher FFS. We could have mocked up prototypes and tested with users in less than a week. When we did test our designs with users we found loads of usability issues. WTF was I doing leaving it so long?
Well, CastRooms is a social streaming product. I felt we could find and fix usability issues later (true). Our riskiest assumptions were actually all about group dynamics. How do people behave in our novel social setting? ‘Good enough’ here was the fastest route to get to real tests in a novel social setting and that took us six months to build. Bluntly, even fast research cycles and iterations take time, so we traded them in.
I lived with early-stage user researcher embarrassment for six months until we could test CastRooms in the context-of-use that would answer our most important questions.
Then there’s design. The graphic design of our product is barely more than a glorified wireframe. It ugly. Our website doesn’t match the product - neither does it match the promo sites we make OR the ticketing platform our users go through. None of that matches the emails we send or our social media posts. Beautiful design is a key part of consumer products like ours so how is this remotely OK?
This time it’s about money. We don’t have a graphic designer in our tiny team. We do have money set aside for design work but only enough for one pass. Spend that money too early and we risk blowing it on the wrong approach. Spend it too late and we look like amateurs when we pitch. So until now ‘good enough’ design has been about making sure that people aren’t blocked from participating in our test parties by design. We traded in beautiful, consistent design for rapid, messy iterations.
Early-stage design embarrassment is the hardest. I hate showing our work to designer friends the most! But we’ve protected that precious budget for when we need it most.
Closely related is marketing. Our messaging is all over the place. Our proposition shifts from week to week as we experiment with different takes. We’ve been through at least three different positioning stances since September. Worse, these changes often mean that one part of our journey has different messaging from the other parts! How can we expect to generate the traction we need without strong marketing?
Well, brutally honestly, we don’t quite know who our customers are yet. We have hypotheses and strong leads but we’re in discovery mode. Great marketing needs a clear audience so our marketing has been…not great. ‘Good enough’ marketing is doing enough to book three DJ interviews a week and get enough people into our parties to test the experience. We traded in performance for short term expediency.
The difficult thing about early-stage marketing embarrassment is everyone telling me what’s wrong. Like I don’t know. But we get the people we need so I grin and bear it.
I’ll touch on development. We don’t have any automated tests so we have to do pure manual QA when we release new things. Ouch. Me and Tommy do it together and it’s boring, repetitive and we miss things. Worse, we don’t support iOS or Android yet even though that’s half the people that come to our parties. What kind of modern web product doesn’t have automated testing or support mobile devices?
The truth is we’re not a proper product yet. Looks like a product to users - website, join journey, social experience. Looks like a product to the business - codebase, deployment pipeline, Linear tickets. But it’s really a series of prototypes / MVPs / RATs to test our riskiest assumptions. ‘Good enough’ development is making this pretty complex thing that lets us run experiments in novel social settings with distributed participants. We made harrowing tradeoffs to build the thing in time for us to learn massive, important things before we start pitching investors.
I find early-stage development embarrassment easier to live with cos I’m not Tommy! But I see what we learned from the sketchy thing we built and I breathe easy.
Finally, let’s talk about data. We didn’t have basic web analytics on our join journey for 90% of the test parties so far. We didn’t add event tracking to let us see what users were doing inside the product until two weeks ago. We’ve collected attendance data since October but didn’t look at it until this year. This feels egregious for a product manager. Isn’t our core skill to be data-led, or at least data-informed?
Well, yes. Except that data - for me - isn’t just numbers. The whole point of running test parties - with real people using a real thing in the actual context of use - was to observe how people behave in this novel setting. We have tons of observational data that has driven product iterations ever since our first test party. ‘Good enough’ data that led to huge intuitive leaps in product design. We traded access to robust quantitative data for better visibility of humans using our complex thing.
I felt lots of early-stage data embarrassment because ‘data-led’ is a truism. But now I’m peaceful with leaving it late because numbers weren’t actually important early on.
Those are five areas where ‘good enough’ in theory has felt embarrassing in practice. They made me feel lesser-than whenever I heard about the wonderful work other people are doing. All these compromises ended up making me feel…compromised.
But I grit my teeth and do it anyway. For two big reasons.
First, at a deep fundamental level, I think early-stage startup life is ALL about finding ways to test our riskiest assumptions as quickly as we can. That’s where we learn the biggest and hardest stuff that leads to quantum leaps. Cantlin put me onto Marty Cagan’s Four Big Risks and that’s a helpful way to think about this. At this early stage I am obsessed with Value Risk (whether customers will buy it or users will choose to use it) and Feasibility Risk (whether our engineers can build what we need with the time, skills and technology we have). Until we’re solid on those I’m not that worried about Business Viability Risk (whether this solution also works for the various aspects of our business) because we don’t have a business until we have something valuable and feasible. And I don’t care Usability Risk (whether users can figure out how to use it) because with numbers this low we can do manual support (we do!) and I trust us to figure out and fix major problems when we test (we did!). Of course, as we get deeper, this risk focus will radically shift.
Secondly, the need for speed is simply overwhelming at this early stage. There are four of us. We have £X in the bank which lasts until Y date and when it’s gone we’re done. We have to make things that give ourselves a chance to find insights that will persuade investors to bet on our future. It’s incredibly stark. It focuses the mind. Suddenly the harrowing tradeoffs don’t only seem possible but essential. Given how much clearer these tough decisions feel it makes me wonder how we might simulate these conditions in larger organisations?
One final thing about speed. Venkatesh Rao recommended the The Perils of Prudence by Abraham Thomas and this paragraph leapt off the page at me:
This is wildly counter-intuitive to me. I’ve burned out several times. Yet despite working just as fast - if not faster - at CastRooms I don’t feel remotely burned out yet.
I wonder if there’s a hidden side effect of making these ‘good enough’ decisions all the time - that I am no longer trying to deliver something to someone else’s expectations of what ‘good’ looks like? Yes, it’s hard work to figure out what ‘good enough’ looks like myself. Yes, it’s hard living with all the embarrassment. But perhaps the act of making ‘good enough’ decisions is protecting me by stopping me working late to polish details that don’t really matter?
Anyway.
This is how ‘good enough’ plays out for me at CastRooms. I’m not saying I’ve made the right decisions every time. I have, as always, made plenty of mistakes. But constantly finding our answer to ‘what is good enough’ is the way I’ve coped with how much there is to do, how few of us there are, and how little time we have.
Reading
I loved reading The Perils of Prudence from Abraham Thomas. In particular it made me wonder how much we talk about Scott and how little we mention Amundsen when we talk about the race to the South Pole.
Listening
I’m hammering Lenny’s Podcast as a crash course in product. This Julian Shapiro episode is a standout. Especially the bit about how we might answer the question “fine, but what’s your moat?”. I needed that.
Watching
I’ve never played the The Witcher so I was surprised how much I love the Netflix series of the game. Henry Cavill is great. It’s funnier and better written than I imagined. And I can’t get “throw a coin to your witcher” out of my head.
Eating
Esther said she was making Jamie’s vegetable lasagne and I was a bit meh. Most vegetable lasagnes try and be ersatz normal lasagne and end up disappointing. But this one is all fresh green vegetables and mint and I can’t wait for her to cook it again.
Right. I’m finishing this off in a manual QA session with Tommy as we fix the crossfader in our party view. Seems totally appropriate given the topic.
Also, I’ve noticed that everyone apart from Esther in this post is a man. Not good enough. Going to fix this for the future.
Will