Even in the unstructured early days of a startup, teams assume and affirm the presence of silos. Product and growth risk becoming distant, connected only by a circuitous, transactional logic.
Tara AI’s co-founder and CEO, Iba Masood (@IbaM), insists on countering that inevitability.
By reexamining standard engineering practices and tying them to growth from the outset, fostering a culture rooted in diversity, Iba and team have done just that and, in turn, have grown Tara AI 1500% in a year.
— Weaving tangible product funnel goals straight into weekly sprints
— “PR zero is the new inbox zero” and other tips for better pull request workflows
— Why shipping valuable features is really a marathon
— How well-prepped workflows and a motivated team culminated into top HN and PH finishes
A systematic, growth-focussed “why” behind every sprint
We did our beta launch in April 2020.
And ever since then, as we took the first steps towards building out a team, we’ve been thinking about one specific thing: How do we set up a methodology where growth is ingrained in our culture?
How do we make sure that growth as a discipline isn’t removed from product, engineering, and design teams, and instead becomes a core driver for their work?
Which meant devising structures, processes, and workflows that a) empowered engineers to make their own decisions and b) had an integral level of routine built in.
Thus we’ve had pods with 3-5 engineers structurally mapped to build around activation, retention, and some of the other parts of the growth funnel. We don’t just target an “upgrade to Node 16,” we say, “upgrade to Node 16 so we can iterate faster and ship weekly.”
Having a growth-focussed “why” behind improving tech debt doesn’t just help devs focus better but it also helps the wider team (marketing, sales, non-engineering) stay well-informed on the core product initiatives.
And on the routine piece, I believe we were able to mostly switch seamlessly to remote work because of practices we had already been experimenting with.
And an early process we debated quite a bit over was the ubiquitous yet often misunderstood, Sprint. Sprints, when done well, can be the lifeblood of startups. We also knew that we could only adopt sprints into our culture and into our product, if we could tie them to growth.
You hear a lot about OKRs these days. But the thing with OKRs is that it can be really difficult to tie them to the day-to-day work and to make teams care about them. Because, unlike sprints, OKRs are typically a bit too far removed and top-down.
So for early-stage teams in particular, and even for product teams at larger companies that need to accomplish a certain goal or to get to a certain version of the product, sprints can be the ultimate unit of productivity.
That is, the performance and effectiveness as realized in the weekly (yes) sprint is an excellent leading marker for monthly, quarterly, and annual success.
Here’s a sample weekly sprint goal: Release new user onboarding to reduce avg time to land in the product.
That sprint goal ties directly into the product funnel. And it can be shipped in a weekly/bi-weekly sprint. Of course, it might take some time to actually realize the outcome after a release, however, when engineers understand that outcome, they know exactly why a release matters.
To zoom out a little, this sprint goal stems from an OKR, which was to “improve funnel conversion by 56%,” that is drastically improve conversions from sign-up to activation to payment. A part of which was to better user onboarding.
In this particular case, we experienced a 7-fold reduction in friction for our users. Our prior product “land time” was 5 minutes and 32 seconds, and our new 6-week avg was 43 seconds. Which was huge.
From the work we’ve done researching and understanding agile (some of us have done it at large enterprises, some have done it at startups), we ended up with a version of agile that allowed both senior engineers and interns to quickly get into the flow of the process.
That happened with a bunch of trial and error, and pondering over questions such as:
- Are we running weekly or bi-weekly sprints? At Tara, we run weekly sprints. Anything longer than 2 weeks feels too long at early-stage startups.
- What complex problems are we aiming to solve?
- Who is the scrum master? Some who’d runs sprint planning meetings — typically a founder, EM or PM)
- Are we having a pre-planning meeting? For most teams that practice Scrum, the Product Owner and the Scrum master will meet to flesh out details of upcoming work before presenting to the team, or host a pre-planning meeting with the team to discuss the next sprints. At Tara, we call this, “Story Time:”
- We typically host these meetings on Thursdays at 9:30 am, right before our stand-up.
- This is the opportunity for everyone to sit down and review upcoming work so the dev team has a chance to think through and ask questions on the requirements, design specs, implementation plan, and work on breaking everything into development tasks.
- Items that are too big for one iteration or infeasible to deliver in the next sprint are split into smaller chunks, modified, or if technically impossible, removed.
- What will the sprint include? How do we scope out the sprint? The purpose of this process is to decide which of the estimated and prioritized backlog items can be realistically delivered in the upcoming sprint. The Product owner starts to move items from the backlog to the sprint until the team is at full capacity. Sometimes the Scrum Master creates tasks on-the-go and assigns them to the responsible engineers.
- Estimation: What sort of tasks can we fit into the sprint? How long will each of these tasks take? Typically determined by the engineers or the EM, and over time, teams show improvement in estimation (predicted vs actual).
- Retro: how did we do in this sprint? Can be a slide during the weekly all-hands meeting; focusing on growth KPIs or movement in growth is key here. There will always be items “leftover” from a past sprint so another question is to decide on what % of the sprint will include critical bugs from previous sprints.
Now, sprints have grown out of engineering at Tara AI. Our marketing team operates on them. Even the operations team, which is completely different, as tasks and goals are much wider and take longer, runs on a two-week sprint cadence.
Aside from sprints, a parallel cause for us was to establish better pull request workflows.
“Going from idea to pull request, more effectively”
What’s interesting is that engineers also form a major persona of our product, so we had similar goals with our product, too.
Our software is purpose-built to make it easy for teams to build, essentially going from idea to pull request, more efficiently. Exactly what we wanted to inculcate in our internal ways of operating.
Sharing some tips and tricks that have informed our pull request (PR) workflows:
1. Set a daily limit on pull requests
Pull requests can take between 2 to 3 hours to review and given that most developers work an 8-hour day, we usually restrict ourselves to 3 pull requests a day.
2. Establish coding standards and guidelines
What languages or frameworks are the teams using? Are there any shortcuts? How are the commit messages being written? All these questions matter. Because if one team member writes code that others cannot read or recognize, this affects velocity.
Which is why we have established coding standards to help our team ship faster and more often. Including considerations such as standardizing the structure and logic of the code so that it’s easy to review and merge.
3. PR zero is the new inbox zero
Due diligence must always precede merging. Our engineering team sets a team of 3 for code reviews. One person who wrote the code and two others to review the code. This minimizes the margin of error and encourages constructive critiques.
The need to review helped us build the “home” feature within Tara, which allows individual engineers and managers to view pull requests that require their attention.
We also encourage engineers and code reviewers to create healthy habits around managing idle PRs. Getting into the habit of viewing them in the AM daily, ensures the team is progressing towards a release. It’s like a version of inbox zero that we like to call “PR Zero”.
4. Syncing pull requests with a project management tool
Use a tool that gives you a high-level overview of your pull requests. While GitHub is great with managing pull requests, it’s not built to manage daily activity around them.
For engineering teams, an agile-focussed tool is ideal to manage the team’s workflow, tasks and track progress.This was an internal need, and we built our PR workflows inside of Tara so other teams could also benefit from them.
We integrate Tara with GitHub to sync tasks with issues. This allows us to see PR statuses, blockers, and check-ins on Tara, in a single view. Engineering managers can understand team performance on a pull request and code commitment level, which can help in assigning tasks and planning future sprints.
Our automations around pull requests also came from our own need to see status on the PR and automatically close certain pull requests once merged.
5. Improve speed of PR reviews and merging with CI Automations
For this, we use Chromatic; an automated tool that gathers UI feedback to help branches correct any possible merging conflicts before deploying the code. It cuts down the time spent by engineers looking for inconsistencies within the code by generating a report on the errors and bugs found so that the team can address those sooner.
6. Avoiding merge conflicts
A great way to avoid merge conflicts is through better communication. Our team uses Slack for internal communication and short-term updates. A brancher will personally message another brancher to make sure the PR looks accurate before sending it off to be merged.
We had also realized how any of these process improvements were incomplete without addressing the more important, people half of the equation.
“The term, sprint, can be misleading”
We also, as urgently, wanted to figure out:
How can we structure sprints to be effective and incredibly more involving for our teams, versus being task-oriented and rote? What does it take (and this is still a WIP) to consistently have top-down goals and bottom-up solutions meet?
For speed of delivery, but more importantly, for effectiveness, it helps that people are adequately well-rested and that that’s baked into the routine.
If you’re seeing engineers committing code late at night, you’re likely witnessing signs of burnout. And founders, CTOs, engineering managers should make it a personal priority to be intentional about proactively identifying such signs of distress amidst the team.
In this sense, the term, sprint, can be misleading. Because essentially shipping valuable features is really a marathon. Some features can take 10 weeks to build, but the work is to break that 10-week marathon down into digestible, workable chunks.
Plus, a big 10-week project has more than a whiff of a top-down task and it can be difficult for teams to be continually compelled and energized behind goals with such huge timeframes. But the sense of ownership on a clear weekly goal is remarkably different.
This also ties to pull-request workflows and collaboration. If a pull request is very large it becomes really hard to review, approve, and have a useful conversation about.
Funnily enough, this belief has also found its way into our product.
So when a PR is merged for a given task, and it’s approved, the task is automatically marked as closed. That was something that surfaced because of our own PR workflow, as we asked ‘why do engineers have to go back and keep updating tasks and updating issues?’
The robotic and tedious process of creating issues and documenting everything can sap so much of creative time. And we really want to get to a place where there’s basically a ticketless future.
Going back to deeply knowing customer problems, aside from being strong believers of using our own product, we document and share all customer conversations with our engineers. As they cannot attend most of these calls live, having enough on their plates already.
As a result, they’re able to place customer journey issues within a broader context.
Another weekly practice that contributes to that bottom-up goal is doing demos during our weekly all-hands meetings. These don’t have to be engineering demos or solutions pitches. A whole bunch of times, it’s just different people talking about customer problems or just any challenges they’ve had while building.
And we’ve recently also baked in meditation time into our all-hands. Just spending a couple of minutes being present, being situated. We’ve gotten a lot of positive feedback for this exercise and we’re hoping to incorporate more of it in our routines.
We really believe that productivity and rest exist together. Whatever the idea of a sprint may suggest, we don’t always have to be rushing and prioritize time to pause and ponder, too.
And then, as we’re thinking through these workable chunks, tying them to growth, and discussing various impediments in the path of better collaboration, we’re also aided by some really diverse perspectives.
As of today, around 72% of people at Tara AI are people of color or women.
And I know that’s far from typical. Especially as we’re in the Bay area.
To share a small, visible example, we have this emoji in our dashboard that indicates a state of WIP within a given task. A brown woman on a keyboard.
And this wasn’t planned at all. That was the first image that came to mind when we collectively picked which emoji would represent the programmer we were building for. It just seemed so natural. She just looked like us.
Leveraging launches as almost predictable growth levers
One of the things that’s really interesting about launches is that organizing for one or two key launches a year can be significant for a team’s momentum.
We typically do two a year and have them fall either in April or October, so we’ve also had set timelines as to when a big launch will occur.
But basically, there’s really two ways of going about it, one is to have the set date and do a date-driven release or the second piece is to not have a set date and say that, ‘oh, we will only do this launch once we believe the product is ready or in that stage/phase to be in people’s hands’
We’ve tried both approaches.
Whatever approach you choose, as long as the team believes in it, that is they believe in what’s being shipped, they believe that it’s not going to break in people’s hands, I think that’s what ultimately matters. The rest follows.
Public launches really do fuel the team. It’s just exciting to see what’s being built, reaching real users, and then getting feedback at scale. Versus never launching. Never releasing. And we also wanted these launches to be consistent, not one-hit wonders as they generally are.
Sprints tie really nicely to this approach because if you have that cadence going then it’s pretty simple to state, “6 sprints from now is when this major launch is happening.”
For example, our product was fully functional 2 weeks prior to our beta launch (we had run multi-month sprints, weekly, preceding that).
Marketing ran their own sprints (we run them in the same Tara workspace, and split into teams/pods running individual sprints, but with visibility into each pod’s sprints based on user levels and access).
Specifically, people focussed on different areas including:
- product hunt community engagement (pinging influencers in advance to check out the product),
- outreach to current waitlist of users,
- graphics and GIFs for the launch,
- emailers to our community of users (these were created in advance).
- We also asked one of our investors (Y Combinator) and their partner Kathrina Manalac, to submit the product and tag the team as makers.
Our PR workflow and release schedule was crucial in meeting our launch timelines and tending to sudden emerging changes.
When we launched on Product Hunt for the first time, we had a ton of traffic from mobile (around 40% of the total traffic), and our onboarding wasn’t optimized for a mobile experience.
So we had to quickly ship mobile-friendly onboarding to support those sign-ups. It meant fixing input fields and the pages to support smaller screens and nudging users to switch to desktop when on mobile, once in the product.
And because we had the sprint methodology and engineering was very much a part of the growth plan, it was just a whole lot easier to make such fixes on a weekly basis as new issues surfaced after the launch.
So our first launch post went to page one of Hacker News and it was trending in the top two. That was huge when it happened because we just weren’t expecting it.
And then that followed with Product Hunt as well. Both happened on the same day. One of the things that really mattered to us was being very open with what were some of the challenges we had faced as we built the product. Again, having the entire team onboard with the launch plan helped immensely.
Seeing hundreds of comments, all that love and appreciation, really drove and continues to drive our strength. Just being able to see that progress as it directly relates to something that we’ve been doing day by day and week by week. 
