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
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.
The Five Mistakes Startups Make When Building for Mobile
In 2009, Farhan Thawar joined mobile development firm Xtreme Labs as VP of Engineering. At the time, it handled accounts for some of the biggest brands in the world — a roster including the largest social networks and popular sports organizations. And they all had one thing in common: They all sensed the urgency to break into mobile in a big way. This trend has borne itself out. Facebook reported last year that 78% of its daily users in the U.S. access the site from their phones. For Twitter, the figure is 75%, with mobile representing 65% of its ad revenues. Unfortunately, there are so many misconceptions around mobile development that many newer startups end up squandering time and money they simply can’t afford, says Thawar. Today he helms engineering for Pivotal Labs Canada following Xtreme’s acquisition, and after years observing what works and what doesn’t, he’s honed in on the top five myths that startups must bust to do mobile right.
Evernote’s CTO on Your Biggest Security Worries From 3 to 300 Employees
Dave Engberg knows a lot about security. Before he took the CTO spot at Evernote, he designed and developed credential validation systems for the U.S. government. If anyone in Silicon Valley knows the value of secure access and keeping information safe, it’s him. Especially now, with publications like TechCrunch reporting breaches and attacks as soon as they happen, these types of events can crush a startup’s potential, especially if they are mishandled. Yet many companies don’t start thinking about building defenses until it’s way too late. After observing his fair share of incidents, and experiencing one firsthand earlier this year, Engberg wondered why there wasn’t a comprehensive guide for how startups should approach security at every stage — starting at the earliest. With this in mind, he gave an exclusive talk at the recent First Round CTO Summit about security and the right way for growing startups to stay safe without needlessly expending valuable resources.