Maintaining the agility of a startup at scale is the business challenge of our times. Like contemporary alchemists, the founders of Google, Amazon and Facebook are preoccupied with the finding the exact combination of big and small thinking necessary to sustain success.
In my last post, I explored the world of Corporate Startups: what they are, why they exist and why some people hate them. Trying to innovate inside a large organisation is like trying to turn a tanker. Matrix structures and institutional FOMO mean accountability and measurable outcomes don’t exist. But a startup must be Get Shit Done or die. As a result, Product Teams must function as corporate commandos, constantly identifying blockers and resolving them in real time.
Facebook’s Little Red Book is a great example of the necessary ethos. Recently leaked by Ben Barry, the Little Red Book is the manifesto of a large organisation trying to retain the principles that defined its early success.
Like Picasso, I’ve borrowed, adapted and straight up stolen ideas from this and other sources for my own manifesto. So, informed by experience, here’s a summary of the key tenets of Product Management success at a Corporate Startup.
Always Be Shipping!
I believe Seth Godin birthed this phrase some time ago, yet it remains the most important principle for any Corporate Startup and likely its biggest challenge. Adherence to the principle of fast, continuous code releases is the outlook that underpins success. Whatsmore, shipping is the highpoint for product-minded people who will be demotivated if it doesn’t happen often enough.
As Paul Graham observed,
“Steve Jobs’ famous maxim “artists ship” works both ways. Artists aren’t merely capable of shipping. They insist on it. So if you don’t let people ship, you won’t have any artists.”
Shipping shouldn’t be regarded as an ‘event’ that requires planning and a complex web of approvals. Shipping is an ongoing process that incrementally evolves the product on a continuous basis.
Working inside a Grown Digital corporation, it’s important to acknowledge that ‘shipping’ is hard and that it doesn’t ‘just happen.’ There are many organisational aspects that stand in the way of shipping anything at all. Large organisations over time have usually developed into cultures that are risk averse. The outcome of this mindset is that they become ‘Default Delay.’
Shipping is to product what working out is to fitness. A necessary habit, not a choice. As shipping is the key to releasing value, product teams should be ‘Default Ship.’ There is always a reason not to ship if you look for one, so don’t look.
Perfect is the enemy of done
The #1 obstacle to ‘Always Be Shipping’ is a desire for perfection. This outlook is ‘default delay’, in the interests of fixing every minor error. In the world of enterprise software, hardware or print products this is understandable as it’s not possible to ‘roll back.’ But in consumer software or SaaS, everything can be fixed, updated or tweaked post-release.
In order to maintain a regular release cadence, teams must be comfortable with making tradeoffs and adopt a ‘fix it in the future’ attitude. As long as the release is stable and there are no P1 showstoppers, teams should always incline towards shipping. There are always improvements that can be made. But typos, brand inconsistencies, minor bugs or the absence of the latest analytics SDK should never hold up a release.
Innovation means killing the sacred cow
Hidden within the Little Red Book is Facebook’s restatement of Clayton Christensons’s Innovator’s Dilemma.
“the internet is not a friendly place….things that don’t stay relevant disappear.”
It is natural for an organisation to want to protect existing products but it’s vital they give new products the independence they need to grow on their own. If you only build new products to shore up existing ones, you will quickly slide into irrelevance.
The web moves faster than apps
This may seem obvious but is frequently overlooked. Facebook famously update their website twice a day to over a billion users. They don’t update their apps twice a day as they can’t. The submission, release and update process on users’ devices make this impossible. Actually, FB update their apps every 2 weeks which is still insanely fast.
Being mobile first should not and cannot mean feature parity or a similar release cadence as the web. Apps should be simpler, more focussed products that concentrate on core utility and requires less updates.
Jocelyn Goldfein (ex-FB and VMWare) recently made this point in her excellent piece ‘The right way to ship software.‘ Apps are actually more like enterprise software, have a lower risk profile than the web and require a slower release cadence. You can’t afford to push buggy releases to a customer’s device as it can take weeks to fix, especially for iOS. Despite being ‘old’ technology, the web still moves fastest.
Meetings must die!
Paul Graham of Y Combinator identified a key disconnect between the world of business and the world of product (engineering and design) when he introduced the concept of the Maker’s vs Manager’s Schedule.
The Maker’s Schedule acknowledges that engineers and designers require units of ½ day at least to be productive. Frequent interruptions to this schedule causes frustration and undermine the team’s ability to maintain ‘flow’ and a fast release cadence.
Business stakeholders, General Managers and Product Managers should establish a culture that eschews meetings and streamlines communication in the most efficient way possible.
In addition to being ‘Default Delay’, corporate cultures are ‘Default Meeting’ as well. Corporate Startups should take the opposite approach and consider meetings a last resort.
Key enablers of a Corporate Startup
A small, empowered team
Autonomy and empowerment are the formula for success. Committees don’t ship fast. Actually, committees don’t ship much of anything. Executive sponsorship should be light touch and ‘informed’ rather than involved in day to day decisions.
Critical to the notion of empowerment is the ability to make financial decisions and direct financial resources at speed. The team must be able choose new suppliers or service providers and engage them almost immediately. Dedicated legal and financial representatives should be in place to facilitate this and there should be next to no bureaucracy to delay it.
In a large organisation, legal teams are shared across all functions and business units and apply common legal policies across all products. For new products, legal compliance can be extremely time consuming and difficult to manage, dramatically increasing time to market.
Key to changing this is understanding that a new product has a different risk profile given its limited exposure and number of users. It is essential that an appropriate risk profile for both Legal and Information Security compliance be established.
Any dependencies the new product team retains on the core organisation represents a challenge to its agility.
The speed of product development is directly related to the Product Team’s ability to control the technology stack, the choice of technologies it uses, the design and UX of the product and the timings of releases. All external dependencies become blockers that cannot be easily managed, especially if they require integration with internal systems.
Some dependencies are unavoidable (especially legal and finance) but representatives from these functions should be carefully chosen according to their support for the ‘startup’ ethos and their ability to find creative solutions to problems rather than obstacles to action.
The team must be aligned around the principle of fast deployment and release frequency. Dependencies on external teams who don’t share the new product’s objectives creates bottlenecks and demands for ‘signoff’ and unmanageable delays.
The more people in the decision-making process, the slower the team’s progress. When the decision-making processes is unclear or contested, as is often the case in large organisations, teams either grind to halt or thrash endlessly.
Practical considerations for a Corporate Startup
Product teams need to own the means of packaging, submitting and releasing their apps.
Again, this seems obvious. In fact, indie Product Teams may struggle to comprehend how this could ever not be the case. But in a corporation with dozens of legacy products and a justified fear of being hacked, the keys to the corporate appstores are often closely guarded.
It’s common for a single team to act as custodians to the appstore and to whom all release candidates must be humbly presented for release. In fact, given a busy schedule, app releases may have to be booked in ahead of time. Meaning that if you miss your slot you may slip your release.
Needless to say, a situation like this creates onerous dependencies and undermines the principles of agility and speed that underpin startup success.
To ensure ownership of release, product teams must have administrative access to respective accounts within iTunesconnect (Apple appstore), the Google Play Developer Console (Android appstore) and the Apple Developer Portal.
If a new product is being submitted as a sub-product within the corporate account, initial submission can be particularly complex. Submitting to Apple requires multiple handoffs between the core iOS team and the new product team. This relates specifically to:
- Provision profile
- Security Certificate and Private Key
It is essential that there is close dialogue (ideally in real time) between the core Engineering / iOS team and the Corporate Startup team during this period to complete the submission.
The Apple / Google relationship
Many organisation feel they have a ‘special relationship’ with Apple and Google. I’m not sure exactly how many industries this affects, but I know media has been a real focus for Apple over the last 2 years.
These ‘special’ relationships always seems to favour Apple and Google much more than they favour developers or Product Team. It’s essential that this ‘relationship’ does not prevent Product Managers from releasing at their own pace. They should not be obliged to wait or hold up releases whilst they update respective Business Development representatives nor should they feel obliged to rework their products as a result of comments that are made.