And into YCombinator
This was originally a much larger piece regarding our experience as a team working under the YCombinator program, but has been slimmed down. The original remains as a point of reference, but some significant aspects, and personal elements, are now no longer part of this three-piece article. Part I can be found here, and Part III can be found here.
The first real sprint of the YCombinator program started after we had landed in Silicon Valley, and the landscape of the project was already shifting with private conversations being held between our resident blockchain expert; Dwayne, and the CEO; Pete.
Dwayne was on a part-time retainer to help us develop his proprietary product in-line with our unwritten product. In the time it had taken us to plan the move to Mountain View he’d created a basic demonstration of the product we were building; a handful of Web forms using Bootstrap, atop his DLT platform.
I began re-building the demonstration as a production-ready solution, quickly re-writing the user interface in TypeScript. I utilized an existing Web application platform developed at my studio, written in Swift, that has a focus on high-performance and low effort to deploy.
One of the huge benefits of the YC program is the ability to experiment with scaling ideas through the vast amount of discounts and credit provided by service companies. We were initially offered free use of Amazon Web Services, Digital Ocean, Google Cloud Engine, and Microsoft Azure. Re-using an existing configuration from the studio, I began work upgrading an Azure-based cluster. It helped that Microsoft were the most responsive of the four companies to get us moving quickly at the beginning, with Google being comfortably last, taking several weeks to respond with a rather oddly worded email that indicated internal politics were at play for the delay.
After the first meeting with YCombinator, since our arrival, the concept was rapidly reshaped. We were told to move away from the simple smart-contract form solution, towards a corporate instant messaging product. This was a drastic change in direction to what had been agreed with the team. Before flying to Mountain View, I’d drafted a marketing-focused brief on the technical achievements our platform would make, on request from Pete, and got to work analyzing how the new products would look in-line with that draft. Pete quickly drafted ideas as PowerPoint slides for 3 interconnected products that would begin with the instant messaging solution. The simple form-based insurance product was now morphing into a complex Slack-like alternative and I was struggling to grasp why, despite numerous conversations.
After a quick review of the push YCombinator had made, and the three products Pete had outlined, it made more sense from my perspective to build an integration product, rather than a messaging platform. My experience with large corporations prepared me for the difficulties in trying to get a potential large client to begin using a new tool. Especially one that would require serious security reviews to be undertaken.
We knew our potential customers had existing messaging products in-use as part of their workflow, and I strongly suggested we’d move quicker by integrating a smart-contract solution into the popular existing messaging solutions via public APIs, rather than trying to replace the messaging products themselves. Much of the burden of security would also be with the third-party providers, and not ourselves. Removing the need to write a whole new visual interface would simplify our initial offering significantly.
My suggestion was ignored, multiple times, in favor of following the external advice to build a whole new messaging product. So I ended the debate by conceding we would follow the product road-map laid out by Pete and the YC coaches, but that it would take a minimum of 6-weeks to get a prototype working, as agreed, and we would be effectively ignoring the first few Demo Days whilst we maintained a focus on the new product.
In contrast, YCombinator gave us 2-weeks to get both the product working, and onboard 5 business customers. They advised us not to hire during this program. We were also told by a YCombinator coach that a developer could write the product in a day with the Python programming language. Advice I frustratingly discovered indirectly, and had no opportunity to counter directly.
First Demo Day
As the first Demo Day approached, despite being a director and CTO, I was instructed not to attend due to not being part of the initial interview process. Instead Dwayne would attend as the technical expert from our team, even though he was essentially a service provider, and not part of the core team. Initially this worked well for me, as it gave me the opportunity to focus more time on moving the team forward, rather than being distracted with trips to the YCombinator offices.
On the first Demo Day since we began coding, we had no product. We had the beginnings of a secure service cluster, we had several components stabilizing, and an automated pipeline from code to deployment. It was an efficient and stable foundation. But not a product. We had prepared Pete for this from the beginning, and none of the team were worried in the slightest, as we had clear and aligned objectives to move forward regardless.
When the duo returned from the Demo Day, they were frustrating and impulsive. They began planning for redundancies in case the development team didn’t deliver, including using a mock version of a chat application running on Dwayne’s proprietary distributed ledger platform. We were asked if our product would be ready by the end of the next sprint, and we re-iterated again that 6-weeks was possible, any earlier was not. The reality of software development was not sinking in, and YC advice seemed to be derailing the plan we’d already established and agreed to internally.
To make the situation more difficult, we were told that, even though we still had no product, the target for the next Demo Day, in 2 weeks, was a working messaging product, with secure file storage, “like Dropbox”, and 15 business customers using it. I suggested we integrate with Dropbox or Google Drive APIs instead, but that was rejected, so we set to work designing a full Dropbox replacement.
User Stories, Workflow, and Time
At the beginning there was a high level of excitement for building a new project. Although the projects were simple, we were energized with the technical challenges we were facing in tackling security, and distributed scaling, suitable for global financial corporations. We’d often have late night discussions beside a whiteboard outlining the issues we were facing, and Dwayne’s proprietary DLT needed continuous refinements to tackle the distributed requirements where data isolation would conflict with the trustless architecture. Although I’d achieved these feats with Hyperledger Fabric and Ethereum, by customizing private and public cryptography patterns, we were pushing Dwayne’s DLT into this space without clear rationale. The mandate to develop a test case for his project seemed to be more important than developing a product for our company.
I undertook two full days of collecting user stories as it quickly became evident our visions for the product were drastically different and we would need to tighten those views into a cohesive set of requirements. I put together a kanban workflow, which we would review in our daily stand-ups, and in more detail in our weekly retrospectives. I took the priority user stories, refined the detail, and added them to our sprint backlogs so we could all see, as a team, where we were, and what we needed to do. Each morning we would agree on what objectives we had as individuals for the rest of the day.
Our efforts were scaling up with our enthusiasm, and we would often find ourselves committing 18-hours of work a day, for 7-days a week. In the first 6-weeks we took a single day off to visit San Francisco, and spent the rest of the time trying to push ahead with the often changing product road-map.
We would take daily walks to discuss what we were developing, and find other places to work to reset our minds, including coffee shops, and co-working spaces. Food was delivered to the house so we wouldn’t need to leave, but I was quickly conscious that the lifestyle habits were beginning to deteriorate so I tried to encourage basic exercise, healthy eating, and regular breaks. The 8:00 stand-ups were enforced, regardless of late night work sessions, to ensure we maintained consistent habits. We had the 12-principles behind the Agile Manifesto pinned to our wall to remind us of the benefits of a sustainable workflow. YCombinator provided some great advice, even if their own coaches often conflicted with it vocally.
We would take it in turns to make meals, and tidy the kitchen. Our meals were taken at a garden table between the rear of the house and the front. It was always warm and light, as we’d sit beside the lemon trees and riff each other, unwinding with beers for some of the team, and ginger beer for myself and Ravi. After food, we’d be back to work until our eyes were red, and we couldn’t focus anymore.
Second and Third Sprints
By the end of the second sprint we had two products ready to go, but neither were part of the mainstream effort. The first was a demo from Dwayne, which the rest of the team, including myself, were not given access to, despite prior agreements. The second was my own monolithic redundancy effort; a single web application that wouldn’t scale — it was a fallback that I hoped we didn’t need to use, but it was available, in case.
We were close to delivering on the official project pipeline, but came up against new infrastructure issues that were necessary to fulfill the “secure” and “distributed” keywords we’d used to sell the product to large insurance brokers. Pete’s own marketing material now conflicted with our rapid development efforts. Monolithic web applications would not be fit for purpose, and it had been made clear that we needed real customers using the product, and not just something to demonstrate an idea.
Every meeting and talk at YCombinator would result in Pete coming back with new requirements, and soon we were being tasked with not only building a Slack-type replacement, and a secure file storage solution like Dropbox, but also a project management tool like Trello. The 6-weeks we planned to dedicate to building a simple messaging interface was sidelined with stretched out discussions on the web site; an initial single-page brochure concept that had quickly spun into a 9-page site detailing overlapping and confusing products that were no longer aligned to our user stories.
At this stage Gabi and I had to leave for pre-arranged plans in the UK, and then a week back in Helsinki to manage studio projects, before we were due back at the house in Mountain View. We both needed this “break”, but were concerned how the project would proceed without us driving it forward on the ground. Leaving a clear backlog of user stories, and agreeing team objectives for the next two weeks, we left for Europe.
This is part 2 of a 3 part article. Part 3 can be found here.