The Spring launch of the Apex 20a platform on March 26, 2020, marks the beginning of an exciting, new era of product development at Apex Clearing. We have adopted a number of product management best practices from the software industry and adapted them to address some of the unique challenges within financial services and software-as-a-service. In the interest of transparency, I’m pleased to share our new processes, what we’ve learned along the way, and where we’re headed next.
Elsewhere in the Software Industry
I joined Apex Clearing last year, having spent the previous 20 years as a software engineer, product manager, and executive, mostly around open source software, including Ubuntu, OpenStack, and Kubernetes. Albeit IBM, Canonical and Google differ from fintech on many levels, these operating systems and cloud infrastructure technology platforms share a number of similarities with Apex's software-as-a-service platform. Moreover, there also exists some literal overlap: we’re heavy users of both Ubuntu and Kubernetes here at Apex.
Ubuntu, OpenStack, and Kubernetes all share similar, predictable, time-based release cycles. Ubuntu has released every April and October, since October of 2004 – that's 32 major software platform releases, on time, every time, over 16 years. Ubuntu has set the bar for velocity, quality, and predictability in the open source world. OpenStack’s development processes have largely mirrored Ubuntu’s, with many of the early project leaders having been ex-Ubuntu engineers and managers. OpenStack, too, has utilized a 6-month development cycle, since 2010, now on its 20th release. Kubernetes came along in 2014, and sought to increase the pace a bit, with quarterly release cycles. Kubernetes is a little bit looser with dates than Ubuntu or OpenStack, but has generally cranked out 4 quality releases per year, over the last 6 years. I’ve been involved in each of these projects at some level, and I’ve thoroughly enjoyed coaching a number of early stage start-ups on how to apply these principles to their product development methodologies.
Across the board, users, and especially enterprise customers, appreciate the predictability of these release cycles. Corporate IT managers are better able to plan, test, and roll out technology changes to their environments, with less risk and disruption. From a commercial perspective, these methodologies drove many wins against legacy, less predictable platforms.
The Key Principles of Coordinated Cycles
As a product development team, you have:
- Time
- Work to complete
- Resources to perform work
To succeed, you must ensure that two of these three are fixed; and only one may vary. In the Ubuntu methodology – time and resources are assumed to be fixed. Time is fixed, in that the product will release, on time. Resources are fixed, in that it takes many months to recruit and hire and on-board new resources. We hire new people, of course, but we’ll assume those resources will be productive in a subsequent cycle. Hence, it’s the amount of work that we will complete, which varies. We will drop or defer commitments, but we won’t change the release dates, and we won't assume additional resources will have meaningful impact within a cycle.
Within Ubuntu, OpenStack, and Kubernetes, each cycle would “kick-off” with a summit or conference, that brought together hundreds of developers and leaders from around the industry, to discuss and debate designs for the release. Anyone who’s participated in an Ubuntu Developer Summit, an OpenStack Design Summit, or a KubeCon Design Summit can tell you how essential these gatherings are, to the success of the project. Within Canonical, we also held a “Mid-Cycle Summit”, exactly at the half-way point of the cycle. We used this checkpoint, as product and engineering teams, to right-size the scope, and ensure that we hit our release dates, and with the highest quality standards. Inevitably, new requirements and priorities would emerge, or some committed work proved more complicated than anticipated. This checkpoint was critical to the success of each launch, as we adjusted the targeted scope for the remainder of the release.
Adapting these Processes to Apex
When I arrived at Apex in September 2019 to lead the product organization, I inherited an excellent team of product and project managers, peered with high-quality engineering teams. Products and projects, however, were managed pretty asynchronously, hence release timelines and new feature commitments were unpredictable. Of course, I had seen this before at a number of the start-ups that I’ve advised, so the model was quite familiar.
Launch Cycles
When adapting the coordinated, time-based release cycle to a given organization, the first thing to consider is the time frame. After talking to all of our stakeholders, 6-month releases, like Ubuntu or OpenStack felt a little too long, a little too slow, for Apex and our customers. Most of the engineering teams were already quite agile and utilizing 2-week sprints, so getting product requirements for 26-weeks (13 sprints) seemed a little unwieldy. Quarterly cycles, however, can be pretty tough to see through, for anything but the smallest individual projects (frankly, Kubernetes struggles with the pace at times). Moreover, all of the projects I’ve been involved in, have struggled with the end of year holidays, in November, December, and January. Thus, we actually settled on a 16-week cycle, which amounts to roughly 4-month cycles. That translates to 3 full cycles per year, with 48 weeks of development, while still allowing for 4 weeks of holidays.
Our cycles are named for the year in which it will complete (launch), and with a letter as an iterator. In 2020, we launch Apex 20a (March), Apex 20b (July), and Apex 20c (November), and looking forward to 2021, we should see Apex 21a (March), Apex 21b (July), and Apex 21c (November). The “c” cycles are a few extra weeks, to account for the holidays near the end of the year. These aren’t really “versions”, as Apex is more like “software as a service”, rather than “delivered software”, like Ubuntu, OpenStack, and Kubernetes. Also, conversationally, we're referring to the cycles with the season -- so Apex 20a is our "Spring" launch, 20b will be our "Summer" launch, and 20c will be our "Autumn" launch.
Summits
Each cycle involves 3 key summits. As much as possible, these summits are in-person meetings (at least until our travel paused along with the rest of the world). At this point, we’re proceeding quite seamlessly with virtual summits, instead. Our summits are recorded in Zoom, and we always take extraordinarily detailed notes in internally shared documents.
- Prioritization Summit
- Planning Summit
- Mid-cycle Summit
Prioritization
The Prioritization Summit brings together our product managers with all of our key stakeholders – sales executives working with new business prospects, our client relationship managers working with existing customers, as well as our own IT, operations, and site reliability engineers tasked with keeping Apex running on a day to day basis. Each product manager works with their stakeholders to gather CUJs (critical user journeys) and map those into patterns of similar, weighted product requests. Product Managers generally spend about 2 weeks on that work, which culminates in a session where the Product Manager presents the consensus priorities for their product area for review by the broader product team. Based on this work, each product manager then starts working on their PRDs (product requirements documents), for the next 3-4 weeks. Our Prioritization Summit is about a dozen, hour-long sessions, spread over three days in the same week. We exit the Prioritization Summit with clear stakeholder consensus on stack-ranked priorities for each product family.
Planning
The Planning Summit signals the end of the PRD-writing period, during which product managers worked closely with their engineering counterparts, digesting all of those product requests and priorities, and turn those into product requirements written in RFC2119-style language (must, should, may, etc.). At the end of that process, each Product Manager and their technical counterpart lead an hour-long session with their plan for the next cycle, including fairly detailed commitments as to the major changes we should expect to be delivered. Our Planning Summit is about a dozen, hour long sessions, spread over three days in the same week. We exit the Planning Summit with clear product and engineering consensus on work commitments across the product portfolio, for the upcoming cycle. This marks the beginning of the development portion of the cycle.
For the next few weeks, product managers spend the majority of their time with Apex customers and prospects. Each of us on the product team carry specific OKRs (objectives and key results), to spend meaningful time with our existing correspondents and prospects, communicating our product roadmaps and gathering feedback on their experiences. We take detailed notes, and all of this data filters directly into our future Prioritization Summits.
Mid-cycle
At the middle of our release cycle (week 8 of 16), we bring together the same Product Managers and technical leads to report on status of the first 8 weeks (4 sprints), and recalibrate the remaining work for the cycle. Without exception, there are always new, late-breaking product requests or requirements that emerge, after the prioritization and planning summits. Some of these are urgent, and we must accommodate, which usually means something else gets deferred to the next cycle. Sometimes, we were a little too optimistic with our work estimates, and again we need to adjust. Occasionally, we’re ahead of schedule and we can cherry-pick some other bite-sized items to bring into scope. In any case, we will exit the Mid-cycle Summit with a very clear line-of-sight on our deliverables by the end of the cycle.
With any scope adjustments well understood, the product team shifts into “go-to-market" mode. Over these next 3 weeks, Product Managers are working with our Marketing counterparts, writing release notes, creating marketing content, educating our sales teams, and working through signoffs on our launch checklists.
At this point, the cycle repeats itself. Once our go-to-market activities are complete, Product Managers shift back into prioritization mode, working with our stakeholders, while the engineering team completes their work and the marketing team publishes the launch.
Speaking of...let’s talk about the Apex 20a Release.
The Apex 20a and 20b Releases
Apex 20a launched on March 31, 2020, as our first release using the methodologies described above. Apex clients can find detailed release notes in the Apex Developer Portal. This cycle began with a Prioritization Summit in October 2019, a Planning Summit in November 2019, and a Mid-cycle Summit in January 2020. This cycle involved 17-weeks of development.
Our work on Apex 20b is already well underway, having held our Prioritization Summit in February 2020, and we’re holding our Planning Summit this week (March 2020). Our Mid-cycle Summit will be held in May 2020, and we will launch Apex 20b in July 2020.
It’s important to note that although we do have a very specific “launch date”, which signals the end of the development cycle, each of our engineering teams have developed, tested, and deployed to production hundreds of changesets during the cycle. Thus, we maintain our agile CI/CD (continuous integration / continuous deployment) systems within every product and engineering team. To be clear, we don’t “hold” anything specifically until launch date. This is a very specific differentiation from Ubuntu, OpenStack, and Kubernetes, which are “shipped software”, as opposed to Apex technologies, which amount to “software as a service”. For these reasons, we try to use the term “launch”, rather than “release”, when we talk about the “launch date” at the end of the cycle. All, that said, we have found the processes described here very useful in our planning and communications about Apex technology to our customers.
In Conclusion
Apex 20a is the first of many coordinated product launch cycles our customers will experience. We’ve adapted many of the best practices utilized by the open source software industry as well as Silicon Valley, and those practices are helping us work more effectively with our tech-savvy client base. Apex will have 3 launches in 2020 (20a, 20b, 20c), and at least 3 launches in 2021. By openly sharing our product stages and delivering a consistent, predictable, and reliable schedule, there are now ample opportunities for both customer input and detailed review and oversight by our leaders, which culminates in secure and stable products for our industry. We’re delighted at the engagement thus far, and really look forward to more collaboration in the future.
On behalf of the Apex product team,
:-Dustin