When a New Feature is Coded, Who Decides That It's Ready to Go Live?
Every day online and offline, CEOs, CTOs, sales leaders, marketers and engineers connect with each other within First Round's Community to learn. They share best practices and give advice freely — and it helps everyone make better decisions, grow and move forward.
We're taking inspiration from this ask-and-answer format to surface the most common questions from inside of our companies and then get the best answers from subject matter experts both internally and externally. We're calling this new series "1:1" and we'll cover everything from engineering to marketing.
To that end, here is our very first 1:1 featuring an answer from Edward Hieatt, COO at Pivotal Labs. He's been a collaborator of ours since he joined us for a session at the First Round CTO Summit in 2012.
Q: When a new feature is coded, who decides that it's ready to go live? Typically QA people make sure the feature works as spec'd. But that requires a well-written spec. Who has time? And that's so non-agile. A QA person could do it, or programmers can check each others' work, but it does seem that ultimately it's the person who has the product vision who should be the one saying "Yes, that does what it's supposed to and it doesn't do what it's not supposed to.
A: Ideally, determining when a feature is ready to go live is a decision that should be made by the Product Manager - the person who came up with the requirements for the feature in the first place.
Here’s how it works at Pivotal Labs. The idea is that in the steady state of product development, rather than using a traditional QA team that relies on a written specification, we integrate the Product Manager (PM) with the development team, and employ strict Test-Driven Development (TDD). The result is a huge improvement in efficiency and productivity.
First, features are defined in the smallest possible increment that represents concrete business value, called stories. Stories are written and prioritized by the PM. Since stories are narrow in scope, the PM can review a story fairly quickly by playing with the new functionality, checking that it behaves as he/she intended. Typically stories take a day or less for a pair of engineers to implement and roughly 15 minutes for the PM to accept. It’s also common for the PM to “look over the shoulder” of the engineers while they’re building it to increase the chances that when the engineers think they’re done, they really are.
Second, our developers practice strict Test Driven Development. This means that as they implement a story, they write unit and functional tests that verify that the application behaves as the PM describes. A piece of code isn’t done until the test passes. And while the PM is reviewing new features, the TDD process ensures that nothing else breaks.
Once the code is checked in and all the tests are proven to pass, the feature is “delivered” to the Product Manager in a staging environment. The PM makes the final decision to either accept or reject the feature. Only after the PM's acceptance is the feature considered “done” and ready to be put in production.
In this environment, a traditional heavyweight QA process doesn’t pull its weight. It’s not that it wouldn’t be valuable - it’s just that it’s only slightly valuable in this setup, and the amount of time spent on it costs too much to justify. Instead, QA resources are best employed using techniques such as exploratory testing. Of course, if a product has a huge audience and a large amount of new functionality is about to be deployed, some semblance of a traditional QA process makes sense.
As Chief Operating Officer, Edward Hieatt oversees all operational aspects of Pivotal Labs’ consulting business, including engineering, client services and the company’s open source product strategy. In this role, he drives revenue growth and performance, and is responsible for managing all regional offices across the U.S. and overseas.
Read These Next
Hyper-Growth Done Right - Lessons From the Man Who Scaled Engineering at Dropbox and Facebook
Radical expansion must be in Aditya Agarwal’s genes. When he started as an engineer at Facebook, the company had fewer than 15 people. Within 6 years, he had risen to Director of Product Engineering, leading 2,000 employees to reach 700 million users. In 2012, when Dropbox acquired his startup Cove, the cloud storage incumbent staffed 30 engineers building for 50 million users. Now Agarwal directs an engineering arsenal of 200+ to protect the data of over 200 million people — and he just worked on yesterday's big launch of Carousel. “Most of what I’ve learned in my career has been during a period of hyper growth and change,” Agarwal says. To grow this fast, leaders need to plan day-by-day for the business they want to be in six months — not what they are right now, he says. How do you build an engineering team to constantly rotate and expand? How do you adjust a product strategy when your company transforms weekly, monthly, quarterly? At First Round’s last CTO Summit, Agarwal shared the secrets he’s tapped to keep his team aligned and productive during the fastest of sprints.
Facebook VP of Engineering on Solving Hard Things Early
January 2002. At Linden Lab, we were still referring to Second Life as Linden World, our furnace-less office was near freezing because the space heaters kept popping breakers, the Dot-Bomb crash was in full swing, DEMO 2002 was 4 weeks away, and 10 programmers were trying to duct tape everything together. Little did we know it was never going to get easier to fix the truly hard problems companies face. I talked about this, among other engineering challenges, at First Round Capital's last CTO Summit.
How Modern Marketplaces Like Uber and Airbnb Build Trust to Achieve Liquidity
In 2009, Airbnb was close to going bust with revenue flatlining at $200 a week. Since then, over 9 million people have used it to find temporary housing. Etsy was founded almost a decade ago, but doubled its valuation with its last two rounds of funding. The gradual but ultimately huge success of these entrants to the marketplace space has paved the way for Uber and Lyft’s breakout growth, and the explosion in startups with marketplace models: Postmates, Getaround, Taskrabbit, and more — quickly eclipsing the old guard represented by Craigslist. Marketplace startups are unique because they aren’t just serving one base of customers. They connect buyers and sellers, service providers and consumers. They have to make sure users are having a good experience with each other as well as their company. As head of product for fashion marketplace Threadflip, it's remarkable to me how much of this is based on our ability to inspire and maintain trust. And while "trust" sounds like a subjective term, building it is highly tactical.