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
Top Hacks from a PM Behind Two of Tech's Hottest Products
Todd Jackson was in a small conference room with a handful of designers, engineers and Mark Zuckerberg. The topic at hand: the Facebook News Feed redesign, intended to declutter the Facebook experience and make it even more engaging. They went over the latest mockups, discussing photo sizes, text density, and the redesigned website navigation. Then they honed in on one seemingly minor point: turning people’s names from blue to black. Jackson, the product manager in the room, knew this was more complicated than one might think. In fact, Zuckerberg had a simple philosophical stance on the matter — that people’s names should remain bold and blue because people are at the center of Facebook. The people are what all the content pivots around, and they should stand out, he said. Jackson’s team had a different contention: in order to more deeply engage its audience, Facebook needed to evolve to showcase content first. In this conversation, Jackson had to wear multiple hats. He needed to absorb Zuckerberg’s argument. He needed to advocate for his designers and engineers. And he needed to think through all of the other pieces and people these changes might touch: internal user operations, external news publishers — not to mention the site’s users. This usually boils down to two sides of the same fence: founders or executives pushing for product changes, and the engineers and designers trying to build them. Such is the plight of the product manager. And Jackson knows better than most. As a PM on Gmail during his time at Google, and on News Feed at Facebook — and now as the CEO of his own, newly-launched Android startup, Cover — he’s worked through tough problems with some of tech’s luminaries. If anyone knows how to balance multiple interests, it’s him.
What You Want in a VP Eng from the Recruiters Behind Twitter and Zappos
Years ago, real estate success story and $1.4 billion company Trulia was in its infancy and on the hunt for a VP of Engineering that would take the site to the next level. It wasn’t going to be easy. The initial team was a close-knit group of hardcore developers led by a pair of seasoned founders, and they weren’t going to let just anyone lead the technology organization.