Today I’d like to share how we plan on working at Seeking Sigma. It’s early days and most of this will likely evolve as we grow but I believe core principles and rituals set from the beginning unleash an enormous amount of speed and potential. Without a set of principles, organizations begin to fracture.
Culture eats strategy for breakfast.
Peter Drucker
Keep It Day 1, Always
One of the most important lessons I’ve learned from Jeff Bezos and Y-Combinator is the importance of sustaining a day 1 scrappy startup mindset and the momentum that comes with it no matter how big you get.
We are ruthlessly pragmatic and strive to keep things as simple as possible:
Avoid work about work (productive procrastination): We’re skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and building the real thing.
Move fast and break things: When things are unclear just set a direction and start moving but don’t waste time in limbo. Changing course while in motion is much easier than from a cold start. I would rather be moving in the wrong direction than not at all.
Use things that don’t scale: Keep the tech stack as lean as possible and don’t fall for shiny object tools. Always use the simplest, usually a doc or sheet until it completely breaks.
Just focus on the next thing (don’t die): I’ve often made the mistake of crafting a vision too grand for me to see the next step. Conventional thinking implies that big things come from big things but they don’t. Big things come from a build-up of small things over time. Yes, we need some direction but most of our focus should just be on hitting the next checkpoint. If we focus on staying alive long enough to get lucky, we will.
Things we don’t do:
Plan big projects around versions with timelines that take months
Use what’s flashy and new instead of what’s proven
Build what we want instead of what our customers are demanding
Things we do:
More in-person work to stay synced and aligned
To launch on time and within budget, we scale back the scope
Full-stack team members
Everyone is a promoter
Start With A Cupcake
I now believe in always building the smallest unit possible and being as scrappy as possible.
The quicker you can get feedback on what you’re thinking the better your idea will be. Usage is oxygen for ideas.
The above from a Peter Merholz presentation shows two ways to plan out baking a wedding cake. The classic way people think about baking has them focussing on the individual ingredients, each of no value to the end user. You can deliver the base first, then the filling, and finally the icing. Only at the end of the final phase do you have something edible; something you can learn from.
Alternatively, you could start with a cupcake. You’ll learn the flavours you like, uncover any problems in your kitchen, and in general you’ll fast forward the feedback loop. You can then step up to a regular-size cake, safe in the knowledge your ingredients are all fresh, your oven works, and your flavours are nice. Only then can you deliver a wedding cake.
The key difference in approaches here is how quickly you get feedback.
Every iteration in a product or even a feature must deliver value, both to the customer and to the business. There is no value in icing or a cake base as a standalone product. They can’t be consumed, tested, or improved upon independently. You can’t validate the idea behind it, or make a better estimate of the cost-benefit analysis.
Whenever we decide to build a feature, we always ensure we’re building a cupcake and not an element of a cake which isn’t useful to the user by itself.
Buy > Build
We’re a small team with limited resources. If we can avoid spreading ourselves thin on development, we will. As a rule of thumb, we buy the best off-the-shelf solution for everything that is not the core problem we're trying to solve.
Even if the solution is more expensive than building and maintaining something in-house, if we free up some energy from accidental complexity, we can channel more focus towards our goals.
The best example of this is our decision to use Clerk for authentication in our app. This saved us engineering hours while giving the user a better experience and freeing us from any ongoing maintenance or bug fixes related to that part of our app.
Our Pyramid Of Clarity
Alignment across our team is always going to be a problem. Currently, because it’s so early there’s so much to do it’s easy just to lock in with focus and lose track of what everyone else is doing. As Seeking Sigma grows, communication will bottleneck alignment.
Nothing is worse than completing tasks and not feeling the weight of your contribution in the big picture.
Asana developed the idea of a pyramid of clarity. We love it and so we stole it. The idea is to ensure that every task worked on by your team connects up to projects which connect up to goals which connect up to the company's mission. We want everyone in the team to feel like their work is leading up to something bigger than themselves and influencing the company in a meaningful way.
A core element of this is deciding as a team on our OKRs (Objectives & Key Results).
Objectives are big motivational initiatives like “Successfully launch MVP” and Key Results are measurable checkpoints like “50 upvotes on Producthunt”. All key results should be specific, measurable, achievable, relevant, and time-bound (SMART). Objectives should always have 3-5 key results but no more.
Everyone has access to the OKRs and everyone has at least one key result they are responsible for. All projects (and therefore tasks) are connected to key results. Key results deliver the objectives and objectives are how we achieve our mission.
Here’s what we have now:
To keep things simple, we decided to start with just 1 objective shared between us. Once the current objective is achieved, we’ll do a temperature check and decide on the next.
We expect trying to find product-market fit to often feel like being lost in the desert. Whenever we feel lost, we’ll circle back to this as our treasure map.
Turning a startup into an optimisation problem
While having long-term direction is important, the prioritisation of what to focus on in the short term can be difficult.
Paul Graham: Startup = Growth
Unlike other types of businesses, startups are designed to grow quickly. For a startup, achieving a high growth rate is crucial. The pursuit of WoW growth shapes the culture and influences decisions, priorities, and the overall mindset of the team.
Paul Graham’s essay and the story of how by treating their business as an optimization problem, focusing on simplicity, user experience, scalability, and continuous improvement, the Collison brothers built Stripe into a highly successful company highlights the importance of using a Northstar to orientate your priorities.
As we move through phases of our journey we’ll select one north star metric to track and monitor the growth rate week of each week. Every week tasks are reprioritised around achieving this - we only focus on what moves the needle.
Delivering on Key Results could take weeks but this weekly metric gives us a pulse on how things are going right now and if we need to change course.
We’re going to start by tracking conversations with potential users and then metric by metric move up to revenue. We’re aiming for 5-7% WoW growth.
Communication
This is another area we plan to nail alignment on:
Write > talk: Wherever possible type instead of talk. If you have a big idea to pitch, take the time to write out a proper memo. Typing forces you to think things through and articulate, saving everyone a lot of time and potential confusion. Meetings are a last resort.
Everything in context: All communication about a specific task, status update, project, milestone or goal should be within the actual item itself.
Projects always have briefs: Outside of our scrum product process, if we start any projects we’ll make sure to clearly define the end deliverable and the timeframe to deliver it.
Listening To Customers
We collect as much feedback as we can: Every day we talk with our customers. We’re using as many tools as we can for that: Intercom, Slack, Twitter, LinkedIn DMs, and emails. Every team member is empowered to run user interviews.
This is important because I believe in the early days, a large group of the people we interview will come from our personal networks and everyone in the team must have a sense of who we’re building for.
Customer feedback is a gold mine but it often gets lost and doesn’t turn into action.
Whenever we get feedback from a customer, we post our notes on a Slack channel.
We then use a form to capture the feedback internally (so there is some standardisation) and turn it into a task. We then organise the feedback based on importance in our backlog. We use a state column to keep track of when requests are shipped so we can update the users:
Building for user stories
In the past, I’ve made the mistake of building for what I thought the market wanted instead of building what it was asking for. We don’t plan on building any features unless we know who wants it - their name and contact details along with an explanation of why they want it.
Whenever designing a feature we plan on always having a user in mind by name, someone to ask if we have questions on the use case and an initial early adopter to test and get feedback from. It’s much easier to design if you can go back and forth with the target customer about how things should work.
I strongly believe that the best products are products built to solve your own problems which is why I will be the first user. Our MVP will consist of 3 features designed to solve pain points I have in my own revenue generation efforts for Seeking Sigma.
After our initial MVP, we plan to store bugs and feature requests in our backlog. We’ll then systematically arrange them based on impact and effort. Once we decide to move forward with a feature we’ll draft a user story containing: the intended use case, the designs, the expected outcome and answers to any technical questions.
Never start development until the feature has been properly scoped with 100% clarity. This eliminates any confusion and saves us from wasting time building the wrong solutions.
We don’t launch, we ship just in time
Here’s how we plan on running our product development:
We use scrum and work in 1 week sprints which run from Monday to Sunday. By only planning for the next 7 days, we’re able to make changes quickly and adapt to the market. At the end of the week, we reflect, review and write a changelog to communicate progress to potential investors and our customers.
Why 1-week cycles
The goal with this is to commit to a body of work and then consistently deliver it. Consistently delivering is what creates momentum and since both GTM and dev teams work within cycles there’s greater collaboration between us.
Aim for ‘x’ points per week: Everyone commits to delivering ‘x’ points per cycle. We’re still figuring out the best way to determine how many points each person should be responsible for. The goal with this is to ensure weekly consistency and make sure that we never underdeliver on our potential but also don’t burn ourselves out.
Scope constraints: We scope the user stories based on what a single full-stack engineer can build in one week. This forces us to simplify and eliminate unnecessary complexity.
We’ll always only have a single roadmap or source of truth for our product. No team will ever work off their own roadmaps.
We don’t separate engineering and testing
I agree with Atlassian’s methodology around not separating developers and testers as roles. It certainly doesn’t make sense at our stage. The developer should be full stack and own the entire product process. As Jack (our CTO) is building, he must test the features himself and roll it out to users himself. Jack must also handle any technical or bug customer support himself.
This makes sure that engineering is connected to the customers and cuts down communication lag to ship.
Connected to GitHub issues
Once stories and designs are completed, the engineer should come up with a well-defined task list to implement. Github tracking issues should be created here and connected to the tasks in Asana directly.
GTM handshakes after push
Agile methodology is commonly only used for engineering teams but I want the GTM teams to also participate in agile cycles. I want everyone to work off the same system.
I want to create a handshake between GTM and engineering where in one cycle week, engineering ships a feature and marks its status as “ready for changelog”. In the next cycle week, the GTM team creates a campaign for the feature: Go to the users who wanted it for feedback + reactivate old users with new features + use the new feature as marketing to attract new customers.
The final stage in our product development is a completed GTM campaign, NOT shipping the feature.
Weekly Changelogs
I’ve seen this adopted by many successful startups and I believe it’s the way to go:
Early believers can follow us along our journey. Users can buy our software both for what it is right now, and what it will become!
Momentum - When you keep getting better week after week, the momentum feels unstoppable. By writing up a blog about what we’ve shipped, it forces the engineering team to think about the customer impact of their work.
Faster feedback loop - As we release new updates weekly to our users, we get to start conversations with our most engaged users about what we ship. It only takes us a few weeks to verify our assumptions.
Aside from the above, I believe the key benefit lies in us having product marketing without a product marketer. We're a small team of builders. We don’t have a marketing team we can rely on. The weekly changelog is a way for us to stay top of mind with potential investors and customers without any extra effort! This helps us both activate and re-engage users that didn't activate over time!
Rituals (How this works in practice)
Daily
Standups (synchronous): Classic scrum standup. We love working together and having at least one face-to-face interaction each day.
We keep communication within the context - usually inside the task in Asana, on the Google doc in comments or as a thread within the Slack message.
Memos for complexity - When a topic requires to be unpacked in-depth, we’re writing a well-thought-out memo.
I’m constantly repeating the company’s vision, strategy, and goals whenever I can - keeping alignment means consistently being reminded.
Weekly
Building products is a team sport. Every Sunday we have one big meeting as a team and cover:
Changelogs: We write these together to take stock of what we shipped in the last cycle.
Post-cycle reviews: We document and take stock of our learnings during the week.
Cycle planning: We sit as a team and tend to our backlog. We run an intense planning session. Running this process altogether raises the question “Why?” we should work on X or Y. We comprise and make sure everyone is bought into the cycle before starting on Monday.
OKR updates: We update everyone in the team on the progress of our Key Results and adjust priorities based on our WoW NorthStar metric
Monthly
Monthly journey update: We post an update on our blog where we transparently share the ups & downs of the past month. These monthly updates synthesize the topics covered in our weekly cycle reviews and also talk about our growth and runway. When we keep our runway visible, it reminds us that startups are by default dead.
We host gaming nights once a month. We meet and play online games. Currently, our game podium is:
Skribbl
Gartic
Krunker (my personal favourite).
We go to market, ALL the time
Although we have specific campaigns devoted to features in our cycles, we should be looking for customers all the time.
Startups often spend most of their resources developing their products. By the time they try to ramp up their sales + marketing efforts, they’ve run out of money.
G. Weinberg, Traction
This is why from the onset, we spent 50% of our time on product development and 50% on traction development. We can’t predict which traction channels will work; the only way is to test them.
Consistently refining our customer
We have a single source of truth spreadsheet that is constantly updated in real time based on what we learn about our market. It consists of:
ICP
IAP
Market trends we’ve identified
Breakdown of our target personas jobs-to-be-done (JTBD)
Unit economics (CAC, LTV, ARPU etc)
Customer feedback
GTM channel strategies
Everyone in the team has access to this and can contribute as they speak to users.
Everyone is a promoter
I’m a big believer in building in public and I don’t believe we need a big marketing team if everyone writes content about their role and shares what we’re building.
Conclusion
Our ways of working are who we are and it’s why we’ll win.
I consider our company as a product itself and as such we’ll always be iterating and changing our ways of working as we grow.
With the loftiest aspirations,
Courtne
