Two years ago, I was a practicing architect (designing and delivering buildings). Things changed fast, and now I spend my days sharing product, talking to customers, writing code & building brand for our company Moot,. Before we started Moot, I built another product that was in and around the consumer social space. Although many of the lessons I learned went directly into Moot, it was the first piece of production software I had ever written myself, and it was a gruelling challenge. It was my first experience working in tech, which doubled up as my first experience building a tech company. If I had to go back to correct things, I would wish upon two things. I wish I had understood the principles of what effective product development looked like and I wish I had understood the advantage of building a system before building a product.

Back then, I just about knew how to code, design and ship (the reason why I was able to raise a decent amount of money to startup), but I didn’t know how to prioritize effectively, set meaningful goals, or keep the momentum up week after week (for either myself or the team). While at the very beginning this is not that critical, it becomes more when you get to the stage of having a product, team and users to support. You need some structure to keep making meaningful progress and avoid going around in circles (coincidentally, the name of the product was Circles).

Now we’ve got a great workflow, some of which I learned some of this as we went through the motions, and more so as I we reflected on how to build effectively. I wish I had this understanding then and would have been able to focus more on the right things, and ultimately avoid a lot of pain!

When I tell people about my journey from architect to solo founder, I often get questions on how I managed that transition to building product in the early stages. This is the now the basic model we use as well as some advice on how to think about product development in the early days. So this post is centered around how to think about effective product development - systems, time, energy and results. Or at least how we’ve thought about them to build Moot in a few short months, while having a lot of fun in the process.

—

P.S. As a remote (and async) company, we built Moot in part to make it easier for anyone to build, giving people a tool we wish we had the first time around building a remote org. One that was simple, customisable and augmented sound remote collaboration so we could spend more time shipping great products, and less time figuring out how to figure things out.

Pre-execution

This won’t be relevant to a lot of startups, as my situation for starting was quite unusual, but it’s important to set the system in stone before you begin doing anything. This is particularly relevant after a big milestone such as raising, or being able to move full time into building.

What does the system entail? Mainly people. Having the right people, but also extends to execution strategy, defining milestones, and also backup routes. It might take two, even three months to get it right but the dividends to reach, productivity, and energy are worth it.

What we did wrong before: The biggest mistake was continuing to build on my prototype pre, during & post-raise. Despite being a solo founder with a bunch of money in the bank, I took on too much frugality and ‘move fast’ mentality to stop to think what we needed to really make moves. Everything came together over time but at that point we had a bunch of sub par systems for building and evalutating progress.

What we did right this time: This time, we took our time to figure out what we were going to build, how we were going to do it, and what the triggers were for continuing (customers willing to pay) and triggers for stopping (no customers). We kept the same frugality but made sure we had enough resources in the team to have direct responsibilities for outcomes & we made those outcomes clear.

Summary: Move slow to move fast.

Execution in the early stage

Once you set up the system, you’re now off to the races. As a new startup, you operate with a non-existing, or small user base, unfinished product, and limited understanding. In those early days, it’s better to aim to move fast as possible, try things out, learn and then fix and adjust. Momentum matters.

This was something I knew in theory as it’s pretty much now startup 101. But in reality, moving fast is as much about having the correct systems in place, as it is about urgency. It’s not about throwing things at the wall or moving forward at all costs. It’s about doing the most you can, with the least amount of effort and resources.

The structure aims to keep up pace and momentum week after week, maintain the team’s health and avoid going in circles. You should keep these structures and tools lightweight as possible and make sure each of them has a purpose and it aligns on delivering value to the user. Reflect between cycles as iterate on what works, swiftly remove what doesn’t.

What we did wrong before: Regardless of the context, we just kept building.

What we did right this time: We setup six week cycles which were long enough for developing micro-projects and short enough to keep perspective. We then took a week in between each cycle to strategise as a team about want went right and wrong. Each cycle has a set of tickets that are defined, assigned to an appropriate DRI (directly responsbile individual). We are also a remote team, so we take the week in between cycles to meet IRL and celebrate the wins.

Summary: Focus on building the right system, then the right product.

Build with users

Much of the early startup process is about learning what your customers want. The general consensus is that you should seek out users or potential users for feedback, iterate, and be flexible to meet the demands of your customers and the market. We did this from the get go yet it failed to materialise, why? It’s too easy to rely on feedback loops and forget about results.

Have high expectations to determine whether you are building the right product

First, just because someone has used your product or is a potential user, it doesn’t mean they are going to give you appropriate feedback. You may talk to users who have a lot of feedback but who aren’t in your target demographic or aren’t it now. If you think you are building for things for early-stage startups, listening to an enterprise customer will likely set you on the wrong path and it’s unlikely that they will even become a customer when you build what they say.

A point to mention here is the need to set regular goals, and reflect on the outcome. You might be getting great amounts of user feedback, and you probably are, but don’t let user feedback alone dictate what you build or whether you’re moving in the right direction. You can become too reactive to user feedback. If after two or three cycles things aren’t moving to the level they need to be (as defined before you begin), maybe you need to rethink from the bottom up. Pushing for payment or a having high expectations for usage (in the case of social, virality and retention) provides a filter to make clear cut decisions on doubling down or dropping out.

What we did wrong before: Working in consumer social, it’s not exactly a typical to go down the paid route. However, our launch showed us that people were eager to pay for what we were building as a way to ensure integrity and accelerate an alternate business model to ads. This was our goal eventually but we kept it in the distance to focus on getting a grip on our users.

How we corrected it: With Moot, we found that defining pricing to charge from the get go made product feedback more pointed, as if they were prepared to pay (or paid) they actually wanted a better service. We kept building with users a priority, as we did before. We also took to opportunity to then refine the pricing model (and still are), based on user feedback.

Summary: Have high expectations. Either launch fast with the aim of getting strong traction, or charge early. Ideally both. If it doesn’t work, tend towards resetting.

Launch and Keep Launching

People often think there needs to be a singular moment for launch. This doesn’t have to be the case and a lot of times many startups launch multiple times. It usually works better than having one massive launch. The problem with massive launches is that it takes time to prepare and they are riskier. There is also an increased risk that the launch won’t work and all the work is wasted. By launching multiple times, you are building your story and brand over time and compounding the interested people have. Each launch builds more following, which then helps your future launches.

Secondly, in the first months or years, your product is likely not a fit for everyone. It’s better to launch early, start getting users and momentum, than trying to wait for that perfect moment.

Similar to changelogs, launching keeps reminding the market about the fact your company exists and you’re making process.

What we did wrong before: With Circles, we were very open with what we were building (aka, no questionable ‘stealth mode’ decisions..) but we did not make any consistent marketing efforts until the product was fully ready. Our Hacker News launch trended on the homepage getting us thousands of visits and subsequent downloads in a day. However, it was too late. The spike was not enough and our energy levels were too low to figure out a rebound.

How we corrected it: **With Moot, we launched by announcing the company before we had the product built. We launched when we built out our vision. We launched when we were open to users. We launch every day when we post about what we are up to, or ideas we are working on. We decided what channels were most likely to return results, and got to work on bringing them to life.

Summary: Iterate on your external image everyday, just like you do with your product.

The Golden Cycle

I talked earlier about our move into executing six week cycles. This was by far the best thing we did for the discovery of Moot. Building a great company is essentially a sequence of great ideas & its generally not going to happen that all the decisions at the beginning of a new product or initiative are going to going to live up to being great. It’s a process of discovery, of trial and error and ultimately reflection. I don’t think the process of R&D should ever end, and it should be the primary function of a company until hitting product market fit.

So on that note, the six week cycle gave us two things beyond a typical two week cycle or worse, a perpetual build process. These two things were a space to think & a space to course correct. This idea came from reading Shape Up, where this is what they had to say:

Once a six week cycle is over, we take one or two weeks off of scheduled projects so everyone can roam independently, fix up something, pick up a pet project, reflect, and generally wind down prior to starting the next six week cycle. Ample time for context switching. We also use this time to firm up ideas that we’ll be tackling next cycle.

Note: These are not sprints. Sprints and work don’t go together. This isn’t about running all out as fast as you can. It’s about working calmly, at a nice pace, and making smart calls along the way. No brute force here, no catching our collective breath at the end.

You’d be surpised at what you can built in six weeks (we certainly were). And the key to unlocking it is to scope in advance. Plan and set expectations. Hammer scope until it’s crystal clear and before you know it you will have carved out great features on time, with plenty of energy to move onto the next.

In summary: Don’t be so busy as to drive out thought. You might just miss a great one.

Try Moot

Moot is an all-in-one workspace that makes remote work a multiplayer experience, so teams can collaborate better, faster and cheaper. Get started today and make remote work engaging for your team.

While you can use any tools or use no tool at all, we’re building Moot to give companies a real space to collaborate and make remote engaging. We’ve got more and more operators getting in touch to use Moot every day, and we’re defining the category of the multiplayer workspace.

Moot is the all-in-one workspace for remote teams. Initially Moot substitutes for quick, human fuelled, real time collaboration. As a multiplayer workspace, we’re building block blocks for everything you can imagine. Brainstorming, note taking, face-to-face calling, chat, celebrations and more. It’s a fully customisable, plug and play system to build your virtual exactly how you need it to be. This pure modularity is what makes us different.

Does that sound exciting? If so, get in touch, book a demo, partner with us. Whether remote, hybrid or async, we're building the infrastructure for the future of work & we want your company to be part of the journey. Let's make it great.