‘Ship. Iterate. Repeat.’ A tactical guide for engineering leads

Context

A core strength of any high-growth startup is the ability to move quickly, iterate based on feedback, and effectively launch new products. However, the process of optimizing for these ambitious timelines (and setting the team up for success) is just as important to get right early on.

New products by definition have a lot of unknowns, whether it’s customer appetite, build complexity, unknown unknowns, or third-party vendors. As a past founder, I struggled with these existential questions all the time since the answers weren’t clear. Though there was always a tendency for action, we had to ensure we were moving in the right direction — moving quickly in the wrong direction could be disastrous!

Through the process of launching Instant Payouts, we iterated on the framework for thinking about these types of new frontier ideas. We put together a set of tactical processes, tips, and learnings on product creation from the perspective of an engineering lead to help other teams effectively execute products with incomplete and rapidly changing information.

Here’s a detailed look at how Brex launched Instant Payouts over the second half of 2020, and the tips and insights we gained from it.

A Product is Born

In mid-2020, we started focusing on one of the biggest challenges small business owners were facing: lack of capital and cash flow. A large part of the problem is that when companies sell through platforms like Amazon, Shopify, or Square today, it takes days or weeks (and sometimes months) between the time of a sale and the time cash from that sale hits a customer’s bank account.

These slow platform payout cycles have become a painful fact of life for small business owners. Our team felt that Brex customers deserved better, and it became clear we needed to act quickly to introduce this functionality. The idea to introduce our own Instant Payouts product, providing merchants with the ability to access their earnings instantly after a sale, was born.

When we decided to undertake this ambitious cross-functional project, we knew that we’d need to stay incredibly disciplined in order to ship the product on time. Q4 is the busiest quarter for ecommerce merchants, and given Instant Payouts’ central role in making Brex Cash the best bank account alternative for ecommerce, we knew we had little room for a slipping timeline.

As Instant Payouts was set to be a Tier 1 launch, we needed to align on a target launch date well ahead of time so that all cross-functional teams could anchor on that date for their own internal planning. This was especially crucial given our work with external parties for press launches, sponsorships, and partners. Concretely, for Brex’s Engineering Product Design (EPD) team, this meant working backwards from the target date to drive deliverables.

Our ‘Capital Team’ was also a brand new team at Brex, joining a new part of the organization as part of our 2020 reorg. In fact, three of the four engineers on the team were also new to Brex, having joined that March. This meant that just as we were kicking off the Instant Payoffs sprint, we were also setting up all of the processes that would enable us to efficiently execute. Needless to say, we learned a lot.

This guide will be divided into two parts:

• First, covering each of the components of the Instant Payouts product development lifecycle and the various processes our team used — and iterated on — to get us to a successful launch.
• Second, a deep dive into Instant Payouts milestones and learnings.

Part 1: Planning & Execution

Going from a stated vision to a tangible product in the hands of the customer requires the right balance of planning, coordination, and process-guided execution.

Our Guiding Principles

We found it useful to have a set of underlying principles the team wholeheartedly believed in to guide our execution. These guiding principles helped us make faster and better decisions while also introducing a framework for thinking through tradeoffs.

#1: Ship. Listen. Iterate.

The team made a deliberate upfront decision — communicated to XFN stakeholders — that we would launch an imperfect product in order to get early feedback from customers and minimize time-to-value. Yes, there would be gaps, and perhaps some things we could do to make the customer experience better, but the main focus was to solve the customer’s core need: instant access to capital to help grow their business. As we talked to customers, we would then course-correct and adjust based on their feedback.

This iterative mindset wasn’t just limited to product execution, but included constant improvement on the team’s internal processes as well.

Optimizing this engine is one of the highest-leverage things a manager can do to supercharge their team.

#2: Ruthless Prioritization

Before scoping engineers, and to determine build teams, we decided on an ambitious launch date. This forced us to focus on an alternate lever to ship on time: ruthless prioritization of just the core-flows, and constant descoping to get a minimum-lovable version of the product out to market on time.

#3: Parallel Execution

A key component of the team’s ability to launch a complex product so quickly was for all of EPD to move in parallel. In a typical waterfall model, Product creates a set of requirements, Design creates the UI/UX, and Engineering develops the software. At Brex, while we practice Agile development, we still follow the pattern of PRD → Design → Dev — albeit in much faster cycles.

Given how quickly the team wanted to launch to customers (first customer onboarded in under 2 months!), we took that process to its extreme by having all of EPD move at the same time. In reality, even if we exhaustively tried to conceive everything into an exhaustive PRD up front, we’d miss out on things as we were still ironing out the nuances of the legal structure. Hence, the team dove in to build the foundational pieces that we had the clearest ideas about, such as handling money movement, locking incoming ACH payouts, and the Amazon API integration, for example.

This had a few interesting side effects. Each function of EPD stepped up to provide input into the other functions. For example, Brex Capital team engineers would propose certain designs that helped make the user experience more intuitive, or propose creative ways to descope product requirements without impacting the end user. In some sense, each member of the team was empowered to have a growth mindset and think like a founder to get things done. Nothing was another person’s problem, since all our work was in service of the job our customers had hired us to do: provide short term capital.

#4: Stay Close to the User

In the early stages of product development, you sometimes have to do things that don’t scale. A team needs to spend a ton of time in user interviews going through proposed flows asking users for the biggest problems they faced, and listen to their feedback.

On our Capital team, oftentimes we found ourselves unsure how to best communicate something to the user, or explain why we saw certain anomalies in a user’s Amazon integration. We quickly learned that getting the user live on the phone, we could get these questions answered much more quickly.

These calls weren’t just limited to Product, but all EPD team members were able to listen in on calls so that the customer context would always be top of mind.

Setting High Level Milestones

To fully embrace the iterative mentality, the team set several milestones as part of its milestone-based rollout framework. These milestones helped the team identify slippage early & rectify, kept morale high, and reduced risk.

We shared these with our cross-functional partners so they would be aware of the team’s roadmap.

1. First Customer Ready (Initial Test) — An internal milestone of onboarding the first customer around one-and-a-half months after beginning to develop the product. Though large parts of the product wouldn’t be built out by then, we wanted to use this to push us as a team to focus on the absolutely critical flows necessary to test out the product and get early feedback from users. This milestone provided the whole team/XFN stakeholders with a crystal clear objective. It was a forcing function for the team to be focused and ruthless in our priorities.
2. Beta Test period (6-weeks) — We onboarded more customers during this period over the course of two waves, during which we worked on automating different portions of onboarding and risk monitoring policy, and continued to build out more features. The team used this period to learn more about usage patterns and used that to refine the risk policy and ops workload.
3. General Adoption (GA) — We turned on Instant Payouts onboarding and access for all eligible Brex Cash customers and had them sign up in a completely self-serve way!

Implementing Our Engineering Processes

While introducing so many processes may sound antithetical to moving fast, the team still needed to be predictable in its output as it attempted to turn complex problems into a delightful user experience. These processes helped us surface issues early on in the process, maintained a pulse on team health, anticipated potential problems, and helped keep the company up to date on our progress. There are some products where you can afford a clunky customer experience in the early stages of development — but financial products do NOT fall into this category.

Initial Scoping and Planning: Document Everything

The engineering-led design documentation presented an excellent opportunity to de-risk the product build by allowing engineers to delve deep into the complexities of the product, define the architecture, models, APIs, and protobufs. The 2 weeks that the team of 4 engineers spent on this process was time very well spent since it allowed us to estimate the timelines for the various versions of the product we could ship.

For Instant Payouts, we first separated the IP product into multiple workstreams and assigned DRIs (owners) for each of them.

In standard Brex fashion, the team began to create detailed design docs highlighting the various systems that would need to be built and how they would interplay with existing services. These needed to be quite comprehensive since we’d be working with 3 XFN engineering teams. On top of that, we bootstrapped 3 new services, so it was critical to get all the interfaces and service architecture correct.

Product had written a high level Product Requirement Document (PRD) that the Eng team based their designs off of, but since we were having conversations in parallel with Legal and Risk, we knew that some requirements would materialize later. Hence the team focused on the portions of the product that were highly unlikely to change, as the base case had good ideas for how to build some of the more uncertain pieces.

Embrace the Daily 15-minute Standup

The team wanted a place for everyone to get together each morning to discuss the work they accomplished the previous day, their plans for the current day, as well as any blockers or discussion topics. This was a great way to:

1. Gauge that everyone was working on the most impactful tasks in real time.
2. Have a forum to discuss things that affected the broader workstreams with the group.
3. Get feedback or resolve blockers.

These standups were tracked in our system (we use Coda to track product roadmaps), serving as a repository of the team’s work since its inception.

A few logistical tips

We tried to schedule the standups next to other meetings, so we could maximize maker time. We strived to schedule the Wednesday standups asynchronously so that they didn’t interfere with “No-Meeting Wednesdays,” and skipped them on Fridays since sprint planning would make it redundant.

The Power of Sprint Planning

Since the team was on a tight timeline to ship the product, we set up a modified sprint planning process to ensure that we’d be tracking towards our milestones. Here were the rough steps we followed:

There were a few pre-work tasks the team did to help make the sprint planning meeting efficient.

1. Each engineer would update the list of tasks they completed in the past sprint, along with an estimate of how long each task took. This was useful, as we could compare it against our estimated story points when the ticket was created in an effort to continually refine our ability to size tasks. The team roughly followed a Fibonacci story pointing system. After a few sprints, we quickly got a sense of team velocity.
2. Each engineer would have a list of highest priority Jira tickets for next week’s sprint. Generally this was easy to pull from the backlog since each person was working on well-defined sub-projects within the larger project. If the priority was unclear, we’d align on that in the Sprint planning meeting itself. We’d assign labels to denote priority importance. In Q3 those labels were: FCR (First Customer Ready), EOQ3 (End of Q3), and Scaled. Later, to get ready for General Adoption, we moved to a P0, P1, and P2 labeling structure, where P0s were launch-blocking, P1s were super-amazing-to-have, and P2s were nice-to-haves. We’d have filters for all these on our JIRA board to ensure we always knew what the most important tasks were. We would also assign story points to each of the tasks.
3. Update the Project Tracking Gantt chart that provided a more high level view of each of the separate work streams and how we were tracking towards our FCR and EOQ3 goals. Each week, the DRI for each workstream would provide an update and surface any blockers that may prevent the project from shipping on time. If so, we’d figure out how to resolve the issue, either by coming up with creative workarounds, descoping, or adjusting resources.

After these pre-work tasks were done, the actual sprint planning meeting itself was much more efficient.

1. We’d run through tasks from the previous week and do a small retro to see how we could have improved our estimates or discuss any unexpected things that came up.
2. Discuss the Gantt chart for high-level tracking, and then go over tickets for the next week. This meeting took about 45 minutes on most days.

A few caveats when it comes to Sprint planning — we needed to account for time spent not actively building features. This included:

• PR Reviews
• Testing/integration time
• Planning time
• Unplanned bugs
• Meetings including team weeklys, XFN syncs, 1–1s, Company-wide meetings, Eng forums, etc.
• Smaller architecture or code design alignment that comes up post design doc phase
• Observability and monitoring

All in all, we found that allocating about 8 story points (i.e. about 4 days of work) was a good cadence to strive for, but the team heroically pushed to knock out 10–12 story points during crunch time weeks.

Helpful Learnings

• When working on a project that has parts you or your team has never touched, grab 30 mins with an expert in the area to help you size the task. For example, since we were a new team and didn’t have any folks who had ramped up on Brex’s codebase, we asked experts within the team to help us size the initial dashboard tasks (the team were incredibly collaborative and we couldn’t have done it without the ‘One Brex’ attitude)
• We found it super helpful to have sprint planning on Fridays so that folks could hit the ground running on Monday. It was also a nice way to end the week, especially since we’d have the sprint planning roll into our weekly Happy Hour.

Team Weeklys Drive Product Improvements

Having a weekly cadence to surface the business context and XFN developments around the product to the team in real-time was critical to our success. We’d also use this forum to discuss business risks associated with the product and arm everyone with enough context to be empowered to surface product and design suggestions. As always, we’d record all the discussion topics so folks who couldn’t attend would know what was discussed.

We also did a weekly “Word of the Week” where the team shared: what’s been top of mind for them, a non-work related win, and a picture from the weekend. We found this a great channel for building team camaraderie, especially in a remote world.

Biweekly Retros Keep Your Team Learning

These retros were used to surface areas of improvement for the team relating to development and work life balance. We set action items during this retro and assigned owners to ensure that action items would be followed up on.

More tactically, we used these retros to quickly course correct and improve processes in an effort to remain nimble. It’s helpful if one of the members of your own team can help run these retros.

Make 1-on-1s your #1 Priority

As a manager, it’s important to internalize that the team is your #1 priority. Taking the time to be well-prepared for your 1–1s, writing down discussion topics, delivering weekly feedback / kudos, and assigning action items are critical to any well-functioning team.

We used this time to discuss the product’s outlook, consider user feedback, engineering priorities, or anything else that was top of mind for both the manager and the IC.

This was also a good opportunity to gather a weekly pulse on how folks were feeling about the internal milestones, or if there were any procedural changes we could make to increase happiness, efficiency, and work life balance.

The Importance of Pulse Checks

Though the team was sprinting towards getting the product to market, it was important to have a good read on team morale, energy, and burnout levels. We’d conduct pulse checks alongside the traditional Brex quarterly surveys to have a more real-time view on team health. These would be used to invite further discussion in team weekly meetings or individual 1–1s.

Within the team, the pulse surveys showed that the team felt a lot of pressure to deliver, which was inevitable given our aggressive milestones and the amount of visibility the product had. We quickly worked to descope the product, streamline processes (more maker time blocks), institute better team norms around late-night messaging (slack notification schedules and scheduled messages), and communicate that the first customer goal was an internal goal and not committed externally.

Weekly Thread Posts Keep Progress Visible

An important part of any large project is to provide visibility for the rest of the company on the progress being made.

Every Friday, the team consolidated all of the progress made on Engineering, Product and Design (EPD), Go-to-Market (GTM), and Relationship Management (RM), and shared a Threads update to all of Brex. Each week a different “Threads goalie” from the Engineering team would take lead on organizing the post. They would tag all of the folks involved to provide a short update in our running doc before consolidating and posting to one of our team channels. Sharing this responsibility allowed all team members the opportunity to share progress with the rest of the company.

Another benefit is that it helped the team focus on delivering value — or getting closer to doing so — each week and served as a forcing mechanism to make significant progress with each update.

Developing a XFN Collaboration System that Works

While the products that your team works on will have different levels of cross-functional collaboration, you’ll need to invest in a smooth process for managing the communication and alignment. This ensures that teams are moving in tandem towards the same ultimate goal of a successful product…. One Brex!

For our team, we collaborated with literally every department at Brex due to the surface area of the Instant Payouts product. To do so effectively, we came up with a working model for each collaboration that let all teams execute effectively.

Weekly Stakeholder Forum

We held a weekly forum to update all XFN partners on the progress of the product, surface any blockers, and align on any discussion topics that required input from multiple teams. We ran a weekly XFN meeting from IP kickoff in July to mid-August. Once we got closer to the First Customer goal, we morphed the meeting into a Launch Readiness meeting to explicitly track each team’s updates and how we were tracking towards our launch goal.

The importance of this meeting cannot be overstated — given the sheer number of folks across the company who were involved in Instant Payouts, constant communication was critical to the success of the product. It let us get ahead of problems and clearly established what each team was responsible for on a weekly basis.

Keeping Engineering Teams Fully Synced

Given the amount of different engineering teams that would come together to build Instant Payouts, and XFN EPM team came up with processes that would ensure that partner engineering teams were always in sync and had all the context they needed.

We held weekly syncs with all partner teams where the broader group would align on the top priorities for the week, surface any asks or blockers, and any discussion topics for the entire group. Each collaboration had a dedicated Slack channel for ongoing discussions during the week.

Developing Risk Policy

We held near-weekly syncs with the Risk team where we’d analyze data from Amazon customers, discuss specific risk policies for onboarding customers, ongoing monitoring policy, and other situations. As we got more information, these policies would evolve, sparking constant discussion among engineering, product, and risk. Like with any new product, without a ton of usage data the policies couldn’t be tremendously sophisticated, mostly acting as a placeholder until we had enough data to build a proper model.

Essentially, we were building these policies while engineering was already in the process of building the core features of the product — another testament to how teams need to work in parallel to get to a launched product.

Regularly Looping In Legal

Since the legal structure for Instant Payouts was quite onerous, there were many details that needed to be ironed out after we decided to use the payout factoring structure. Every week, we would work with legal to translate the legal requirements into engineering requirements and vice versa; in effect, surfacing features that would be very difficult to build in product to see if there was a creative way to solve.

Often, these requirements aren’t black and white but rather open to interpretation. The team focused on fulfilling the spirit of these requirements in order to provide the appropriate customer protections. As a team, we found it helpful and often faster to propose potential solutions to legal requirements instead of waiting for outside counsel for specific solutions, since, as an EPD team, we had specific knowledge of the feasibility of certain builds. In this way, we could be partners in coming up with solutions, presenting them for legal signoff.

Bi-Weekly Ops Sync

From the very beginning, the team had an explicit goal of making this product as self-serve as possible in an effort to reduce cost-to-serve for our customers. However, we knew that to get to FCR, we’d need to rely on Ops help for manually verifying that customers satisfied the risk criteria and collecting signed program agreements from those companies that passed.

We worked with the team to create internal tooling pages that would provide all the necessary visibility, with the strict contract that our team would automate onboarding, monitoring, and other flows as soon as possible.

In our bi-weekly Ops syncs, we’d surface the efforts Eng were undertaking in order to make the product more self-serve, talk through updates to the internal tooling page, and align on any further support the team would need. We used an Instant Payouts channel to share looms on progress and discuss any topics that came up during development and planning.

This dialogue was important in helping the EPD team keep the self-serve goal.

Developing Strategy with GTM

Product worked closely with the GTM team to align on marketing plans and GTM strategy for all growth funnels including partnerships, sponsorships, paid advertising, launch press, and updating brex.com copy. Weekly syncs were essential in aligning the teams on launch date as well as for sharing on-the-ground learnings to inform SB ecom GTM strategy / messaging.

Relationship Managers

As we onboarded some of our earliest customers, RM was actively involved in soliciting customer feedback, and helping the customers through the manual onboarding process. This was an important avenue to collect early pain points from customers — in fact we got many of these customers on Zoom calls with the EPD team to learn more about their specific feedback. Much of this made it into the product before launch!

Part 2: Deep Dive into Instant Payouts

Milestones

First Customer Ready (Beta Launch)

We knew we had set incredibly ambitious internal goals, which meant that the team didn’t have a ton of time to do the exhaustive testing that we would later prioritize for General Adoption (GA). At the same time, we wanted to get customer feedback as soon as the core flow was working.

In fact, when we onboarded the first customer during this week, we had the customer sign program agreements when onboarding via Docusign, since the core flow we wanted to test was advancing funds based on sales data from the Amazon integrations and collections.

On the week of 8/31, after working with Relation Managers and Ops to ensure the initial set of family-and-friends customers had completed the onboarding tasks, we enabled access to IP for these customers. Over the next few days, we iterated on the data model and program logic based on the initial usage patterns and edge cases we saw.

For example, we saw that some customers had their own websites — not an Amazon storefront — and accepted ‘Pay With Amazon’ payments through them. This resulted in some messy data coming through the API integration which we moved quickly to address.

Unpredictable events such as these are hard to plan for even with rigorous planning, so it’s always super useful to get to the point of testing with a friends-and-family customer as soon as possible. The team did several of these fixes the first week we began testing with customers. Make sure to keep enough buffer time for these fixes!

Another great thing the team did with the FCR framework was making sure to build a simple, yet highly scalable design. We didn’t want to get to FCR in a one-off way, but ensure that whatever the team was building would scale to a GA-ed product. We’d continue using much of the functionality we built for our first customer even as the product grew much more complex.

Learnings

The beta period is inherently a period of listening and learning in order to understand how to find the bottlenecks in product adoption. Product did a great job putting together a Learnings doc outlining what went well and what was needed to optimize PMF for the product.

It’s important to note that we explicitly used these learnings to tweak the product before GA. If we had waited longer, we wouldn’t have learned these things until the big launch week, which would have impacted many more customers. This also helped inform our roadmap of fast follow projects.

GA Readiness

Given that we had about 6 weeks to get from First-Customer-Ready to General Adoption, the team had to get back to prioritization. Though we had validated the core flows, the focus now shifted to making the product self-serve (ie. building the entire onboarding flow), more lovable, and lower risk by implementing automated monitoring. For much of September and the beginning of October, the team worked through these larger work streams in the same way as we did for the initial FCR milestone.

Note that in this period, we balanced prioritization of building new features with product changes informed by customer feedback. As always, we triaged these as a group to figure out which would be most impactful.

As noted earlier, we used our weekly Launch Readiness meeting to coordinate across different functions within Brex.

T-Minus 2-Weeks to Launch

As our launch date approached, there were numerous bits and pieces still needed to launch the product, but not part of a specific workstream. We started chipping away at these approximately 2 weeks before launch.

The EPD leads got together to make a final list of these small tasks, along with their prioritization before moving it over to Jira. We added P0, P1, and P2 labels (with P0 being launch blocking) to each of the tickets, and made filters so everyone on the team knew exactly what would be necessary to get to launch. No matter how small the tasks were, they were all tracked on our board. We wanted to have a consistent view of everything necessary for launch.

We also used this time to do more exhaustive E2E testing on preview and staging environments to have confidence that everything would be working as expected.

GA Week — It’s Showtime!

On GA day, the top priorities were to ensure the rollout plans were being executed smoothly, and that folks internally could follow along with all that was happening.

Stay Visible with Internal Company-Wide Updates

We wrote a company-wide thread in the morning, alongside a Slack channel with real-time updates including press releases, metrics, and such.

Track Your Metrics!

It’s important to have a Looker dashboard set up that can track GA performance, including tracking traffic sources, funnels, and any other relevant metrics. Our team had a dashboard to track GA performance and adoption

It’s important to continue tracking to gauge whether the product is performing as expected, and if not, to quickly come up with a game plan to fix.

It’s also critical to implement the right product analytics well before launch, so the data team has enough time to implement and are able to report out on launch day. Otherwise, the team will have to scramble to put something together — this is something we could have done a better job of!

Avoid Problems with a Code Freeze

When a launch corresponds to a big external event with press involved, it makes sense to institute a code freeze, otherwise Murphy’s Law tends to hit in multiple ways.

Our team didn’t institute a code freeze for any of the XFN teams (just the Eng teams that were directly involved in building the product) — coincidentally the dashboard was affected multiple times that day, which impacted onboarding for new customers.

If we had had a code freeze in place, we could have prevented many of these incidents from affecting the GA rollout.

Time for a Team Celebration 👌 🎆

It’s a momentous achievement to GA a product, so take the time to celebrate with your team! We held a Happy Hour where we played games and provided food for all members of the team. Though we’re always thinking about the next big goal for the team, it’s important to take the time to reflect on how much the team was able to accomplish.

Learnings

How Polished Should a Product Be at Launch?

Throughout the process, the team sometimes had to make difficult trade-offs when determining to the level of polish to launch the product with. This will always be a constant discussion when trying to ship large products with a small team.

Our learnings here were to focus on the job the customer had hired our product to do. If we could do that job in a seamless fashion, then we had succeeded. There were many questions about adding additional features before launch, such as an option to trial the product without rerouting Amazon payouts to Brex Cash, or the ability to offer Instant Payouts for free to the customer if they chose to spend their proceeds on Brex Card.

The team did a quick scoping, but ultimately decided to get to market faster and use that to learn more about customer needs, rather than delay the launch by 1+ months. In retrospect, this was the right call — also our team’s principle #1!

Navigating Risk Policies

The ultimate risk of product comes down to the fact that it’s difficult to predict volumes in new segments.

The team launched with many conservative risk controls in place, which we ultimately pared back as we saw new data and edge cases.

In the future, our learning here is to align on a broad framework for loss budgets and define the testing phase, during which we’ll have very simple — but not negligent — policies. Not only should this allow the EPD team to launch faster, but would also allow the team to learn more about the portfolio of customers using the product. As we gather these learnings, we’ll continue to encode them into the risk policy to responsibly grow our exposure.

Managing XFN Timelines

Given that Instant Payouts was a top level company priority, we needed to ship on time.

As the engineering leader on the team, you’ll have to make practical calls about whether your team will be able to hit ship dates when the timelines are ambitious. The most important thing to remember is communication and visibility. It is fine if the product turns out to be more complex than originally conceived — sometimes it requires really digging into the weeds and implementing to find the hidden ‘gotchas’.

For Instant Payouts, we surfaced to the overall Brex Cash org early so we were able to find folks on the Cash Infrastructure team who were between projects and could help out for a few weeks — this helped us ship important features to customers, such as communications about the new product.

Always leave time for follow-ups

When estimating the lifecycle of a project, it’s important to allocate the time for follow-ups as you learn more information.

As tendency is to immediately begin work on a new product or feature, it’s vital to leave some time to allow the product to arrive at a self-sufficient state. We knew that some changes to the product, such as expedited onboarding, would be huge lifts, but there were also other things customers were letting us know were confusing. We chose to prioritize these in parallel.

As an Eng team, one good way to do this might be to have the ‘goalie’ work on knocking out some of these follow-up tasks. However if you’re a team with a large operational workload, the goalie might not be able to do these tasks. In that case, it might make sense to have this be a rotating position as well, e.g., an engineer can work on these tasks for the entire week instead of jumping between their main workstream and these other tasks every day.

Final Thoughts

We hope this guide will assist teams in launching products quickly and effectively.

While we’ve learned so much building Instant Payouts, we’re always iterating on our processes, so please don’t hesitate to reach out with your own processes and learnings that have worked for you and your teams by commenting below — we’d love to hear from you!