How we decide what to work on
One of the biggest challenges in starting a company is figuring out how to execute your vision. Specifically, even if you're one of the lucky ones to have a clear vision, how do you bring it down to earth, to the blank page of today, and start making progress?
Most people (and that includes us) start by just doing stuff. Not much thought goes into planning, focus, alignment. You just think about what needs to be done. Since everything is yet to be done, everything seems like a great idea. Initially, you make a lot of progress because, well, you're starting from 0.
But it doesn't take long before your calendar is full, weeks go by, and you realize not much progress is being made. You are busy, you are working a lot, but the vision you set to accomplish doesn't seem to be getting any closer.
Product Management process, applied to everything
After a few months of running around like busy bees, we felt we had worked a ton and reached some goals. Unfortunately, we had also accomplished many things that, beyond filling our to-do lists with dopamine-inducing checkmarks, didn't really help us move in the right direction. It's like we were trying to walk and for every step we take forward we also were doing 10 push-ups.
This can result in a very exhausting endeavor that doesn't get you very far. Beyond draining your energy, it also carries the risk of leading you down a very bad path, particularly if sunken costs fallacies start to kick in (and you think you need to do push ups to be able to walk).
From the inside, it felt like we were a team of distracted, uncoordinated cofounders going to put out fires as we saw them coming. It didn't feel right. So we asked for help! Enter Jenny, my wife. Jenny has managed teams of product managers, and I thought: what are we, after all, if not 4 product managers trying to create and bring to-market a product-service? Maybe she can help get our ducks in a row.
Jenny suggested implementing a few basic processes from Product Management 101, and applying them to our building of Remotely. She would also serve as a master of ceremonies of sorts, running the orchestra with her baton (i thought of it more as a cane, hitting us in the head when we did something wrong).
It changed everything. By turning each one of us into a Product Manager, we each took on different responsibilities creating or improving aspects of our product/service (in addition to our day-to-day operational responsibilities). As an example: while we worked on moving sales opportunities through the pipeline, we were also coming up with a set of tests to help us get to a scalable demand generation process. Your day-to-day task (nurturing sales opps into closed customers) cannot be the only thing you do.
Vision > Challenges > Epics > Tasks
Jenny has read most of what one can find under the sun in terms of product development methodology. She suggested we start by getting inspiration from "What is good product strategy" by Melissa Perri. We started defining the Vision Statement, and it didn't take long before we agreed on this
In 10 years, Remotely Works will level the playing field so top developers outside main tech hubs can access the best opportunities.
Now, once the vision statement was set, we needed to ground it in a more tangible, shorter-term strategic objective. She asked us: what feels like it would be a great first challenge to accomplish in the next 3 months that, if you did, would be meaningful progress towards achieving your vision?
We decided our goal would be to place our first 3 developers with 3 different customers. By doing so, we would experience the end-to-end process of supply, demand, and employee onboarding and management. And we would have 3 experiences, hopefully somewhat different to get a sense of variability.
There wasn't any deep analysis that went into decided what our first challenge would be. The logic was as simple as what's written above. At our stage, it was really about assessing the amount of learning/progress that we would get out of working toward this challenge. That's the point, to default to action over a "short" period of time (3 months) with everyone working toward the same overall goal, so you can quickly learn and re-assess your strategy faster. Getting the challenge right doesn't matter much, as it will change shortly after. What matters more is to validate quickly.
Once the Challenge had been discussed and agreed upon, we broke it down into Epics (which can be seen as a large body of work with a common objective) and each Epic broken down into Tasks. Each Epic has an Epic Owner who either owns the tasks within or assigns them to the right teammates. Suddenly we had a clear connection between our day-to-day to-do list (assigned tasks), through Epics and Challenges, all the way to the vision.
Take into consideration what you learned to plan your next challenge
Once the challenge was complete, we took a pause and reflected on what had gone well, what hadn't, and what we had learned. We mapped out the parts of the end-to-end process of our business and placed sticky notes where we felt we were facing the biggest difficulties. We also suggested what the challenge for the next quarter should be. All of this input was used in a 2h session in which we reviewed the data, agreed on the challenge, and identified the target conditions we needed to hit to consider the challenge accomplished.
Again, as the target conditions were agreed upon, we used the learnings from our past challenge to inform what secondary goals we needed to accomplish as leading indicators to make sure the outcome of our challenge would hit our goals. For instance, from closing our first 2-3 customers we learned what our win-rate on sales opportunities was (not as law of nature, but as a first data point observed). That allowed us to make a more informed prediction on the number of sales leads we needed to generate in order to accomplish our new challenge. So our challenge definition and target conditions became much more accurate (less of a wild guess), and also realistic/believable as it was grounded on some past experience.
Keep the tension up with Sprints
During our first 3-month challenge retrospective (the session in which we reflect on what went well and what went wrong), we identified a problem with our cadence. We felt like we'd gone through a few weeks without a lot of progress (which was evident in our weekly progress check-ins). The reality, for us, was that 3 months was a long time horizon that enabled us to procrastinate and not work on our assigned tasks. Urgent things got in the way of important tasks, and with the deadline for the important work still weeks/months away, we punted the ball forward.
On observing this situation, Jenny suggested adding Sprints to our method: vision > challenges > epics > sprints > tasks. We started setting up 2-week sprints in which we defined, for every epic, the tasks we would work on during that sprint, and defined a delivery goal (definition of done) by which to grade the level of accomplishment of that task.
Sprints add a bit of overhead: you need to sprint plan (the first time Jenny helped us individually get our tasks right) which includes setting sprint goals and defining the tasks you intend to accomplish. You also follow each sprint up with a demo and a retrospective. But after completing our first one, we already felt a meaningful increase in productivity and accomplishment.
Doing vs thinking
As we approach the completion of our second Challenge, we start to reflect on the things we could do better. We've already identified a few:
We need to pre-schedule the sprints within a challenge: it gives visibility to the team, allows the team to plan their personal life activities accordingly, and sets the tempo of the organization.
We need a "strategic check-in" mid-way into the challenge. Halfway through the challenge, you may have already completed 3 sprints, and you may already have learned strategic directions you need to reflect and act upon. Waiting until the challenge is completed seems that could be the wrong thing to do, so we are adding in a little more thinking here.
It has also become pretty clear that how you design the tempo of your process will determine (in a meaningful way) how much time each of your team members spend doing vs thinking about what they should be doing. This doing vs thinking tradeoff is something that we will be tweaking and refining as the needs of the business evolve.
A different way of building a company
Over this first year of operating Remotely, I've realized that we started doing something quite different from Olapic. At Olapic, we thought a lot about the "components" that needed to be built in order to "assemble" a company and, then, we did it. At Remotely, instead, we're setting up a process (a formula, if you will) that we hope will spit out a great company as a result. There is a sense of vertigo that comes from not over-focusing on the future, and instead trusting that the process will enable the right paths to reveal themselves. In a way, instead of willing a product into existence, you will a method that you hope generates a successful product into existence.
