My favourite drummer is Matt Helders of the Arctic Monkeys.
I consider him one of the best of this generation, especially in terms of speed, accuracy and creativity. If you don't know what I'm talking about, go look up the song 'The View From The Afternoon' and pay close attention to the drums while attempting to ignore Alex Turner. Impressive isn't it? Even more so if you consider he's doing all that while being stuck in Alex Turner prison playing 70 bpm songs for the last 10 years.
Then there's drummers like Ringo Starr. (My twitter handle is @yelkhayami for Beatles fanboys that want to argue.) Sure, he's pretty good, and the Beatles were great as a group, but musically Ringo has never been very impressive rhythmically, and at times, very inconsistent.
Why am I talking about drummers? Because:
Like great drummers, startups rely heavily on finding a good rhythm. That's why Iterations, sprints and daily check-ins exist, they're rhythms designed to drive progress and build a sense of consistency.
Having a good rhythm in a startup also builds momentum and confidence. There's less time to worry about existential issues and there are more tangible problems to solve. For us, it allows us to do our best work without any worry, stress or doubt.
This month was a bit difficult for us. Between our freelance client expectations, the advent of Ramadan and constant travel, there were a lot of rhythmic interruptions to keep up with. It was especially difficult because we also know the amount of progress we are able to make when we do find that momentum. The previous month is a good example of that.
So we had a nice talk about rhythm this week, and what we can do to improve it. Ultimately we concluded that the best way to find a good rhythm is to focus on one thing at a time. Part-time freelance work and Minimum disrupt the rhythm more than we want it to, but we need it to survive. This actually means that our problem is simple. It's money.
It might sound worrying, but it's not. It only means that we need to start working on a plan to raise the money we need rather sooner than later. It could mean we'll have to start looking for investors. It could also mean us taking off a few months to raise the money ourselves doing work for Minimum.
Luckily, a couple of things are certain. We believe in our team. We believe in this problem space. Now we just need to buy ourselves the time to be able to work on it while having a good rhythm. In the meantime, we're continuing as usual while trying to keep up.
Here's some other things we did & learned this month:
One mile at a time
Shitting on game of thrones aside, we were still able to get some important things done this month:
We're pretty happy with these results. To most people it might not mean much, but to us it feels like we're finally getting the right kind of feedback to start building a good product.
Gathering feedback is not so straightforward
We finally rounded up enough people to give our app a serious try, and we're ready to find all the problems. Right?
Ok, maybe not. We kind of forgot that this was our first try. We also realised that it was unreasonable for us to expect instant feedback for something that requires a drastic change in behaviour.
These people still have ongoing work to do every day. If you want the right feedback, you need to make it easy for them to give the right feedback. In our case, that meant identifying the biggest hurdle in our app: getting started. We're currently solving it by individually onboarding people by hand.
Know when to learn and when to confirm
Talking to users is amazing. Every conversation we have builds confidence that we're focusing on the right problems and lets us learn new things about them. While showing our app to users for feedback, we found that the way in which we framed the conversation had big impact on the kind of answers we got. Basically:
When we framed the conversation around the current version of the app being as-is, we got a lot more tangible feedback and specific requests, but when we framed the conversation around what we think the app should be, we were able to discover all sorts of new problems. Neither of them is necessarily better than the other, but it's important to realise this to know what you want to get out of a conversation with a user. For us in practice, it boils down to:
Frame the discussion around an abstract concept and allow the user to take a leap of faith on a hypothetical.
Frame the discussion around facts, and don't use hypotheticals.
We believe it's important to have both types of discussions with the users. Using this deliberately has prevented us from wasting precious time on things that weren't important enough.
In the coming month, we'll be pouring all of our energy into building a complete experience in Pody. The mini-pilot has helped us find out what most of the missing pieces are. We'll be completing Podys' onboarding and mobile app. At the same time we'll be validating Pody's message and pricing.
Hey dude, let it be done
Some people (with a brain) might say that The Beatles are the most overrated band in history. (Like I said earlier, @yelkhayami) While I'm not going to take an obvious stance on that statement, I'm here to assure you of one thing that isn't overrated: You, dear reader.
We initially started this blog so we could hold ourselves accountable (to make jokes) and share some of the things we learn. Even though it's not a big amount of people, it amazes me every time how many of you read this and talk to us about it :)
As usual, thanks for getting this far, and we'll catch you in roughly thirty days ✌️
One of the things that amazes me is how far you can get with limited resources when you optimise for simplifying things. This of course, is something that developers talk about a lot, but hardly ever do in practice.
I noticed that there is a certain line most developers are not comfortable crossing when it comes to simplifying. At that point, it becomes 'too simple', and gets associated with not being a 'real solution'. Usually, this is when they find out the problem is solvable without code.
Working with no-code tools opened my eyes even further, as a developer with a similar background. Yes, you can simplify it even more and get away with it. Users don't care about your 256-bit encrypted authentication system if all they can do is log in.
I feel that it all comes down to attitude. If you truly care about solving the users' problem, at some point you stop caring about how you do it. If you don't believe a solution is real, how can you expect a user to? Having a crappy solution now is better than not having one at all because you're waiting for the 'good' solution to be ready.
Of course, this doesn't mean 'good tech' and 'good solution' don't have a place. On the contrary, they are essential parts to a long lastig, reliable solution.
You can always decide to scale up and build the 'good' solution. It's much harder to go back and build a 'crappy' solution. You won't even lose much, and anything you lose by repeating yourself you gain times 10 by avoiding big mistakes with a cheaper solution.
So yes, you can simplify it even more.