When you start a business, you essentially bring an idea into the world and make it a reality.
And to make it a reality, you have to start with some basic plans in place: how you will build your business, your product, your team, and your strategy. Rocketlane is our second venture. Having been a fully remote team since Day One and being one of the early entrants in an underserved market, we’ve learned many valuable lessons. We hope this post will serve as a starting point for anyone thinking about starting up.
Let’s dive right in.
We have elaborate conversations with customers and prospects to understand their needs and the problems they hope to solve. Recordings of these conversations (>300 hours), which include discovery meetings, customer demos, etc., are made available to the team. We post highlights from these conversations on Slack to get the discussions going. These recordings are also shared with new employees to help instill customer empathy and emphasize our True North.
We showcased the product features and capabilities via clickable mocks of product features in some of our early conversations with potential customers and users. We did this even before we had any development kicked off, and it gave us some exciting ideas and validation of direction. It also made us think through the initial ‘wow’ moments and observe users’ reactions at each key moment. I’m proud that the team has not built a watered-down version of those mocks but instead has translated it to an even more beautiful and thought-through product.
Let’s take Rocketlane as an example. An MVP simply doesn’t work for a ‘unification’ play like ours where our software would replace multiple horizontal tools that are mature in their own ways. We wanted to enable project management, document collaboration, and communication all within Rocketlane. Now all of these areas have their own feature-rich software. Combining all of them into one platform meant that we couldn’t get away with something that’s just 50% done. We had to build capabilities that people are used to and then add our unique experiences. And our customers find it impressive that we pulled it off.
We started with a straightforward weekly team meeting and two engineering catch-ups per week (Wednesdays and Fridays). Over time, the Friday meeting morphed into what we’ve dubbed as "Demo Day" internally. It has been an excellent way for the individual team members to push towards accomplishing something significant every week and getting reactions from the rest of the team. Our design lead also works with each front-end developer a day before the demo to ensure that what is being demo-ed is usable, useful, and often delightful :).
To ensure that we're working on high-priority items and unblocking team members promptly, we also introduced a daily stand-up that ensures we have no surprises towards the end of the week. All of this was not something we’d planned for on Day One, but it has helped us ship at the right pace and build a solid product amidst the pandemic.
Demos to a few key potential customers created a sense of urgency around delivering some features and experiences. This helped us prioritize and accelerate the right aspects of the product.
We could have hired our marketing and content team members earlier and had our website and content live sooner. By November, we had a good repository of content in our drafts, waiting for the launch of our website. We were running Implementation Stories, our webinar series, already. We also had enough episodes for our podcast, The Launch Station, ready for release. Both these content categories are rich in industry insights and expertise, but we couldn’t go live with them because we did not have a home for them. We could have built some momentum, SEO, and waitlists if we had focused on this area earlier.
We had minor bandwidth bottlenecks from time to time as we tried to add people in specific roles and had to wait.
We could have had a one-/two-month head start if we’d hired a few founding engineers slightly earlier than when we did it.
We hired people who either desire to level up or have shown a passion for their work. We believe that a growth mindset can be inculcated in team members, and we had enough early conversations with ours about leveling up and seeing the opportunity ahead for us. We’re now a 26-member team working towards crafting an excellent product experience.
We have created avenues to amplify and appreciate the right behavior (#appreciation on Slack, team meetings, etc.). We also have conversations with folks quickly enough if we see wrong examples being set by them. We also use the interview process to introduce potential team members to our culture (not mistaken for "checking for culture" in the interview). Finally, we engage in healthy debates, so the team knows it's okay to ask each other the hard questions, hold each other accountable, and have difficult conversations.
Every team member has been working remotely since the day they joined. We realized the need for connection early, and we have a few routine activities that help us establish that connection with each other. They’re all about making the (virtual) workplace fun and psychologically safe. We’ve written about it in detail here.
The team is fully bought in on our mission and enjoys crafting a beautiful product focusing on our customers. For example, we once had an angel investor watch our demo and say it would be nice to have a certain kind of experience for customers (the “presentation mode” feature). I loved the idea and just mentioned it to my team, noting that we should think about it in the future. It got built on the same day and right before a critical demo! The result has been many customer demos citing this particular experience as a ‘wow’ moment in our product.
We may have had too many passionate cooks involved in figuring out the right recipe for some of our initial decisions on frameworks, libraries, etc. We could have adopted a more "commando" approach to saving a few days/weeks. We realized this mistake in retrospect and corrected it subsequently. We also explained to the team about one-way and two-way doors, how we prioritize, and our approach to product building and engineering in general so that they understood how to get comfortable with quick decisions and not get stuck in analysis paralysis.
We started using our product in early December for our document work and bug tracking. It's been a blessing as team members figure out an experience that doesn't work for them and then go ahead and fix it.
This post doesn’t cover every startup lesson you can ever access, but these 13 are from our journey through a year. We hope this post helps you, and do leave a comment if you have anything to add!