Towards the end of last month, I published an article on LinkedIn — Ambitious plan to build a new product in 14 days explaining our plan to build a brand new product — Document360 by bringing the entire company together as a hackathon. We scheduled the hackathon event from December 1st to December 16th (just leaving out Sundays) which gave us 14 working days to execute our plans.
Well, now it’s time to reveal where we are and how we have progressed over the last 2 weeks. It was a fun-filled activity bringing the whole team together and finally seeing a tangible outcome. Let me explain the whole journey from idea to a tangible MVP product in this article.
What is Document360
First, let me give a short intro to the product. Document360 is self-service knowledge base portal designed for software products and projects. The idea came purely out of our learning of building software products for many years. Every single software product (or even internal software projects) requires an online documentation these days. Given your inbound sales are going to be driven by the content’s quality, your documentation becomes the number one source of customer acquisition. We wanted to build a world-class product that makes it seamless to author and publish your product documentation.
You can sign up early beta access via https://document360.com
Our problem turned into an idea
The idea came to me about 4 months ago, when I was looking for a solution to our own documentation challenges for our products. Between August and October, I spent all my spare time researching on the tools & products available in the market (I covered in my original article) and started documenting everything — things like what I like about certain products, what are the gaps in the products, pricing structure; I even spoke with our own documentation team members understanding their day to day challenges and so on.
While we were able to narrow down on to a specific tool for our documentation requirement, after all the research, it gave me the confidence that there is room for a good documentation focused product for software products and projects, taking into consideration some of the requirements we had.
UI/UX Mock-ups
I started off by creating the mock-up screens of the product to help envision how the real product would look like. I started visualizing the full application and I was able to get the full end-to-end flow of the user journey like signup, sign-in, create projects, changing settings, authoring an article, managing categories, versioning and so on. Here is a screenshot of one of the settings screen mock-up.
It took me about a month to finalize on these designs after multiple iterations.
Identifying the technology stack
Once all the mock-up screens were ready, I was confident and able to visualize how the end product will look like. As the next step, I started looking into the technology stack for the solution. Ideally, a product like this will best fit on open source stack like Ruby on Rails, NodeJs backend, MongoDB database, and host it with some of the modern cloud providers with Heroku, Compose, etc. I started prototyping some concepts in a similar way to the UI/UX exercise. Only then I realized it will be a steep learning curve for our team to switch to these platforms.
We are predominantly a Microsoft shop with tons of experience in technologies like .NET, C#, JavaScript, SQL, Microsoft Azure, Angular etc., so I thought it will be an overkill to switch to a brand new platform. I started identifying the technology stack that would fit our team and how we can focus on solving the core problem instead of spending a ton of time learning new technologies.
Finally, I settled down with the following combination — .NET Core backend, Angular front end, Azure Cosmos DB with MongoDB as the backend, SQL Server for some relation data, Azure App Services for hosting. I also evaluated a few third-party products to bring scalable search functionality, user authentication, and payment processing. I was able to prototype and validate key scenarios and was confident with the technology stack.
Hat tip: When you are building a product, especially a multi-tenant SaaS product like Document360, you must always think about scalability, reliability and performance from day one.
Identifying the core areas in the product
At this stage (took me about 2 months), I had a clear picture of how the product was going to look like and the technologies we could use to build the product.
The next step was to dissect the product into multiple small modules. The UI/UX mockups gave me clear visibility of the different sections of the product and I started listing them one by one:
- Article Authoring (markdown editor, diff. viewer, version manager)
- Category Manager
- Settings Section
- Authentication & Authorization
- Landing Page & Custom Pages
- Search
- Analytics
- Import & Export (backup/restore)
- User Portal (end-user customizable)
- Internal & External commenting system
- Payment processing
- Infrastructure requirements (domain mapping, SSL, hosting, backup, DR)
- Continuous Integration & Deployment
- User Interface (screen across the application)
- Marketing & Documentation (pre-launch)
The above split gave me a clear visualization of what needed to be done. There were about 15 core areas in the product that needed to be developed to get a working version of Document360.
Teams to Tasks mapping
Now that we had the core areas of Document360 in hand, I started mapping out tasks to teams and individuals. Given the experience building products, I could sense few of the tasks were best suited for individual contributors while the volume tasks were best suited for small teams.
As a company, we maintain a flat hierarchy and I interact with pretty much every person in the organization. To a great extent, I’m fully aware of the capabilities, strengths, interests, and weaknesses of each technical resource in the organization and this helped me a lot to map the tasks vs teams/individual.
As a team, we have 23 full-stack engineers, 9 QA people, and another 10 people from support, marketing and sales (excluding few people from sales, accounts, and admin). The various skill set of people (experience ranging from freshers to 15+ years) helped us form teams depending on the complexity of the task.
The only objective I took into consideration in assigning tasks to individuals and teams was whether they could create a minimum working version in 14 days.
Presenting the Hackathon plan to the team
Up until this point, I was working alone on the project doing the base work for the hackathon. Doing the research exercise, UI/UX mock-up, technology prototypes, and understanding the team dynamics gave me enough confidence that we can quickly deliver the product to the market.
Early November, I presented the plan in a company-wide all hands meeting “to build a brand new product in 14 days in a hackathon format”. I demonstrated the UI/UX mockups, the technology prototypes, teams vs tasks mapping and everyone was super excited about the concept. I thought this could also be a great team-building exercise, bringing people together, mixing teams and individuals and testing our technical ability to build state of the art products in a short period.
We analyzed the state of all the on-going projects and activities and finalized December 1st to 16th as the dates for the hackathon. This gave enough time for the teams to wind up the activities they were working on and free themselves completely for the 2 weeks period.
Learning and training mode kicked off before the Hackathon
Explaining the project, technology stack and requirements to the team a month in advance gave them time to familiarize themselves with their part of the activity and be prepared for the work in advance. They were able to take ownership of some of the prototypes that I had prepared over the last few months and expanded their knowledge.
We decided to go with Angular 4 as our front-end technology. In any software product/project, majority of the time will be consumed on the user-facing interfaces. Therefore, we wanted to bring pretty much all our developers up to speed for this. We arranged for 2 days of training on Angular 4. We organized this training under our TechMeet360 branding — which meant that even enthusiastic participants from the local community turned up on a Saturday for the session on “Angular 4 for .NET Developers”.
Excellent turnout on this #Saturday for the #Angular4 for @dotnet #developers workshop with hands on lab. @kuppurasu360 kicking off the sessions #msbts #technology #meetup #community #TechMeet360 pic.twitter.com/Q9jcFb1EKg
— TechMeet360 (@TechMeet360) November 25, 2017
Alternatively, over the last few days, we formed a small core team and started doing all the groundwork for the Hackathon like creating the project structure in Visual Studio, sorting out different Microsoft Azure subscriptions like dev, staging, production, sorting out the high-level architecture, continuous integration and deployment pipeline, sorting out user access to source control and so on.
The reason we pulled in people to get started with these activities was that when we start the real hackathon, it should be 100% focused work, without spending time on discussions and meetings.
And, finally … The Document360 Hackathon Begins
Finally, it was December 1st and we kick-started the Hackathon for Document360. We had a customary cake-cutting ceremony to officially inaugurate the start of the Document360 Hackathon.
Teams, daily scrums and “scrums of scrums (SOS)”
We run all of our projects in an agile way — daily stand-ups, user stories, epics and so on. We adopted the same technique, however, with a slight variation. Every team/individual would be responsible for running their own internal scrum processes to move one step forward every day. Towards the end of each day, we conducted a “Scrum of Scrums (SOS)” session where all the team (module) leaders from each team (15 teams) assembled in the open hall and updated their progress and challenges.
This exercise was so important for us to understand the progress, given 40+ people working on various parts of the project. This is the only time we got to know where we were as a team and address any dependency challenges.
We had to iterate and give feedback, make corrections, refactor things every day to make sure we all were heading in the same direction.
Parties and Weekend fun
As a company, we always wanted to mix work and fun together. We strongly believe you get the best output from people when they are happy and enjoying their work. We had few team members burning complete mid-night oil, staying all the way up to 5 am in the morning.
The teams decorated their cubicles with interesting facts and everyone was given a whistle to blow if he or she needs any help (or emergency!) or to signal to the entire team when something (even small) was achieved.
Team outings and parties are part of our culture and how could we miss it when we were doing something at this scale. We arranged for a team-wide party in the middle of the hackathon with a fantastic selection of food.
Since some of the UK team members also traveled to India for the hackathon, the team arranged for a mid-Sunday day trip to Ooty — a famous tourist destination about 2.5 hours drive from our office. Daniel became a celebrity with the local crowd and everyone wanted to take a selfie with him :-).
Final “Show & Tell” of Document360
After 2 weeks of intensive development and constant integration, we finally assembled as a team for the “Show & Tell”, where we worked out an end-to-end user scenario we wanted to achieve and each team presented their part.
It was an amazing experience to see things getting into shape when we started with pretty much nothing only 2 weeks before. Some of the areas were highly technical and required significant engineering efforts, but we were able to witness the product in action during this Show & Tell.
And here’s a look at the Visual Studio Online (VSO) project plan summary at the end of the two week’s Hackathon.
What’s next?
After the 14 days hackathon, we had a raw functional working product, however, it’s far from taking it into production. We don’t want to lose the momentum and wanted to make sure we execute the plan correctly so that we can take the product to market.
On analyzing various projects we are doing at the moment, a couple of products got some deadlines in January and we released team members from those projects to get back to their regular work, safely handing over their part of the task to people who are staying in the project.
We did another “tasks to the teams” mapping and assembled a 15 member team who are currently actively working on the product to polish each and every feature and focusing on taking it to the market.
We are hoping to get a closed beta access of Document360 by the end of December, public beta access by mid of January and taking the product live by the first week of February.
Overall this was an awesome experience and we were able to use this a great team building activity and understand the strength of our team.
Even though the execution of the project happened in 14 days, the actual planning started a few months before. I don’t want to give the wrong impression that you can do a finished product from scratch (without the idea and research) in such a short time. I was cautious, on this scale, if we hadn’t planned correctly we would have simply ended up spending 2 weeks with little fun and no outcome.
Interested in early beta access
We have put together a website with some information about Document360. If you are interested to try out the product, you can request for early beta access.
You can sign up early beta access via https://document360.com
–