How we run as fast as a startup within the walls of a large corporate

In October 2014 I accepted a position with PricewaterhouseCoopers as a product manager with the directive to build a development team to solve inefficient parts of the business using web applications.

Since writing this article a lot of people have been asking me to dig deeper into the methodologies we employee in PwC Ventures  from a developers perspective - A quick peek into PwC Ventures's development methodology.

Our first public product is Nifty R&D, our second is The Vault, and our third is Air Tax.

? ? ?

To the outside observer, the Nifty R&D team’s internal operations may look haphazard. We often adjust our weekly plans, continually shift our development priorities, and change the website several times a day.

That said, the product team is perfectly synchronised, Nifty R&D’s user base is growing week-on-week and everyone, from our team to our users, seems happy.

What’s actually happening is that we’re iterating our feature roadmap relative to customer feedback and usage data so quickly that it would be detrimental to stick to our weekly plans.

Half-built features are actually sets of micro features, each providing a quantum of value to the end user regardless of whether all are ‘finished’ or not, and Nifty R&D is constantly optimising its product-market fit on a very granular level.

We couldn’t do this without some core philosophies in place to keep our (at the time of writing) four-person team grounded.

Push versus pull communications

Push communications require your attention regardless of whether they’re relevant, such as having to open and review an email you’ve been cc'd on. Pull communications allow you access as much or as little information (e.g. from a central inbox) as desired on-demand.

We take the best of both by consolidating all communications through a chat app that filters conversations by discussion topic. It only alerts users when they receive direct messages or are mentioned in a discussion, while still allowing access to all discussions at any time.

Build small, release small

We launch a new update of Nifty R&D two to three times a day. This can only be achieved by breaking down features into tiny segments, each of which independently provides a quantum of value to the end user.

We do this by considering the complexity of every feature to be built, then breaking them down into a series of micro-features, each of which are simple to understand and implement.

Releasing code often ensures an increasing rate of user acquisition and retention by continually optimising the product. We’re currently averaging over 50 micro-features and updates per week between two developers.

Stay focussed and track results

Every feature added to the Nifty R&D roadmap is framed as a problem that affects a user. It’s then triaged against the opportunity cost of not implementing it, which we determine through a combination of user feedback, personal experience and analytics of historical usage.

Before developing a feature, we work out a target to justify it's ongoing development. Once it’s live, if it doesn’t make the grade after a set time period, we remove it from the roadmap entirely. This maintains a focussed user experience and a clean codebase.

Weekly sprints, daily stand-ups

Every morning the entire team attends a daily stand-up where we spend less than a minute each describing what we did in the last 12 hours, what we’re doing in the next 12 hours, and highlighting any bottlenecks. We also do this with weekly ‘sprints’, where we review how and why the previous week’s priorities changed.

This approach keeps the team focussed on their individual tasks as well as the current week’s priorities. It also allows the team to openly address any issues they currently have and provide input on other colleagues’ tasks.

Transparency creates quality

Allowing all of our team to access everything from communications through to financials provides broader context to each team member on terms that they are comfortable with. This enables everyone to get behind a single vision and understand their individual contribution relative to the bigger picture.

This approach eliminates the opportunity for roles or titles to constrain progress. It empowers everyone to independently solve problems to a higher degree of quality than if context was proxied through a hierarchy. I also believe this to be a fundamental ingredient for fostering a supportive team culture.

Stress is a signal

Stress causes bad decisions to be made, which leads to poor quality code and technical debt.  We avoid it at all costs.

The biggest driver for stress is time constraints. As a product manager, I try not to set deadlines for feature development. This way, if one of my team is stressed, I can infer that it’s because the feature is too complex to be solved in its current form and needs to be broken down into simpler, smaller segments.

Summary

We can’t stick to these philosophies all of the time. But they are the fundamentals that Nifty R&D was built on.

Underpinning the success of these philosophies is having the right team. Without employing people that appreciate these points, you have already given your project a glass ceiling. I learnt this the hard way and Mark Zuckerberg frames it perfectly...

Only hire people you would work for.