Balancing Act: Build and Buy Strategy

In most startups, you begin with a hypothesis of how you are going to address a need, and hope to build a product or a solution that can fulfill that need and build a business out of it. The time to market is one among the many pressures weighing down on your mind. How do you execute in this scenario?

1. Build: You can build everything on your own. Though you don’t know what to fully build yet,  you will discover along the way.
2. Buy: You can find other technologies that address certain problem in a generic way and bundle (integrate) those to create your product. ¹
3. Build and Buy: You can build what you think is the core competency that your startup is going to focus on, and buy/acquire the other peripheral components to create your full offering.

Sometimes building everything on your own is stupid, why would you want to waste your time and resources in solving problems already solved. And you can’t just buy everything and cobble together a unique product that is worth something. So you have to really come up with a Build and Buy strategy for your product to both be uniquely valuable and addresses time to market. Time kills startups.

So if you are in charge of building the product, you are bound to face all these pressures coming from your CEO, CTO, Marketing and Sales visionaries in your company. And this is where if you are not careful, you will end up building something that probably takes more time, is not elegant, and does not add any real value. And thus, if the product has no real value, how can you expect your company to establish itself as a viable business. The paranoid around you will start proposing ideas, most of them tend to be hare-brained, spur of the moment types coming from really loud voices in the organization. This is the time when you have to stand strong. After all, you are there to build a new product that offers a new and unique value proposition and change the dynamics in the market.

I have gone through this experience myself and wondered if I and our product team caved to these pressures and simply bundled what is out there already in the market, would we really be a product company or just another integrator? Where does innovation rank? Where is the IP that is going to make your company highly valuable and set us apart? As a product owner, you need to really think hard and have the courage, conviction and vision. You need to lead and convince others that what you propose to build will be more valuable than just cobbling together a piece of other technologies. At JackBe, we established very early on that innovation was going to be the key value my team was going to live (or die) by, and as such, we went against the opposing forces time and time again to innovate and really build the core technology and IP that established JackBe as the market leader in enterprise mashups and real-time intelligence. Our product gained customer admiration, won several awards and eventually, the company was acquired by Software AG because of the value of our unique product and IP.

I am not saying that your complete product has to be 100% home-grown, every line of code written by your team. There are plenty of FOSS products for you to build your unique product or platform. And there may be commercial products or components that you might want to OEM and license to build your product. There is no need to build those from scratch. That would be silly and a stupendous waste of time and resources. The key is to identify what is core to your differentiation and what is commodity, and then build your core by leveraging the commodity components out there and that’s how you balance the forces and address the time-to-market. Some common commodity components to consider (I only mention a few to just illustrate the example)²:

• Server Side (Java Based): Application Server (Tomcat/Jetty/etc.), Application Frameworks (Spring, Akka, Play, etc.), Utility Libraries (Apache Commons, Apache Axis, Saxon XML Parser, etc.)
• Database Systems: RDBMS (Apache Derby, MySQL, etc.), NoSQL (MongoDB, Redis, etc.)
• JavaScript: jQuery, jQuery Mobile, Prototype, Angular JS, etc.
• Visualization: Fusion Charts, High Charts, D3, NVD3, etc.

So my message to you is this. Don’t just bundle other COTS to create your product. It won’t help you to build a revolutionary new product. Instead make  your own unique and secret sauce and mix it with what is commodity already to create a high value game changing product.

---

^{1 – Buy: For the purpose of this discussion, I am using ‘buy’ very generically. In some cases, you don’t really buy, but you can just acquire it via partnership. For open source products and components, you just use it (beware of what open source license they come with and their restrictions there upon. My favorite FOSS licenses are Apache 2, MIT, BSD. I tend to stay away from GPL (all versions) and LGPL.
2 – Free or Commercial: Note that some of the components are open source, and some are commercially available sold by other vendors in an OEM friendly license that you have to acquire from the respective vendor for a price.}

Advertisements

Engineering Methodology: Theme Based Releases

In continuing with the previous blog on engineering methodology, I wanted to talk a bit more about how to work the requirements funneling and release management process.

One of the challenging aspects of building a product is to figure out which requirements make sense and which don’t and keep the features in line with the product’s goal and philosophy. This gets compounded by what is pushed by sales (if the product had this, i can close a huge deal deal right now!), inspired ideas from visionaries in your team (build it and they will come), your own insights based on the product and customer knowledge (many customers have asked for this), and a myriad of other things.

One approach to manage this is to use a Theme based development stream. A theme basically focuses on one or two large related areas of need in the product. Getting different stakeholders to agree on a theme is much easier than to get them to agree on individual requirement priorities of disparate items. These themes become the place holders and guidance for directing an incoming requirement. And the themes can then be mapped out in terms of relative priority and lined up for the release milestones. Aim for the theme to be delivered in less than 3 months, and each feature in the theme should be done in sprints of no more than 3 weeks.

The themes are flexible. You may have to add or remove features to the themes at any given time. However, if a feature is already in development, most often, it is too late to remove it from the theme. In quicker releases, you might map a single theme to a release to keep the scope down. In larger releases, related themes may have to be released together, but be careful about combining more than 3 themes into a single release. Once you have the themes in your pipeline, you can then sequence these themes into milestone releases. In my experience, this approach allows efficient and effective allocation team members to complete the features and also allow them to work on multiple themes. This way, the entire team can be busy working on delivering one or more themes, and therefore, one or more releases.

Themes also make it easy for your marketing and sales teams to articulate the value of the next release to current customers. Instead of digging out the nuggets to sell/promote from a large list of features listed for each release, you end up having upfront agreement on what the next release is going to be all about. So while the engineering team is working on development activities, marketing and sales teams can work in tandem on collaterals, outreach and other launch related activities. This allows for closer collaboration and more efficient cross-team work to achieve a successful release every time.

JackBe Engineering Methodology

Often I have been asked by customers, partners and friends, what methodology we use at JackBe to deliver our product releases. The closest I have come to describe it is to brush it off by saying we use Agile development methodology. But that is just scratching the surface. When you dig me in for more specifics, I end up scratching my head to explain coherently. So I thought I would share my thoughts briefly to see if I can catch the main message I want to convey about this topic. For a brief comparison of the various approaches under the agile umbrella, see what Martin Fowler has already said about that subject.

At JackBe, the methodology we adopted was crafted out of several approaches and stabilized over time. The number one goal was to keep delivering the releases and features, and not let processes get in the way. And we did that successfully over the past 7 years, averaging 3-4 releases per year, which I believe is a significant and consistent achievement in enterprise software products business. Let me discuss around the 2 most popular methodologies and my take on how they were relevant to our approach:

• On XP The values espoused by the XP approach (Communication, Feedback, Simplicity, Courage, and Respect) were fundamentally intrinsic to our team, and that took a lot of time and effort for us to cultivate initially. However, once this was in place, as new members go on the team, they quickly absorbed and contributed to the approach and became an integral part of the team very quickly. However, though we initially started with a bit of Test Driven Development (TDD), but over time it became hard to maintain that in our development cycle. This often meant, that tests took the back seat to other aspects of development, but we were only accumulating the technical debt, as testing the software later racked up the bill. The number of unit tests we were writing as a team dropped drastically as the rush to push out new features became a business priority, and this is one of the traps that most development teams fall into.
• On Scrum While Scrum recommends a periodic sprint (say monthly) that the entire team coalesces around delivering, we sometimes adopted this principle. However, we did not follow the daily scrum meetings and there was no Scrum Master to do this. Instead, we valued open and continuous communication between all the members of the team including myself so that no task would get held up in order to reach the goal of delivering a software milestone. Our team did not wait for daily scrum meetings, we just took up the issue as it arose and resolved it. We did have the weekly team meeting as it was necessary to get everyone aligned and re-aligned to ensure we were making continuous progress. But the main work of communicating and aligning was done daily on a continuous basis allow the weekly meetings to provide a wider update and status check for the team. Many others in the industry who use the Scrum approach rigidly, have complained that the team finds the daily scrum meetings which should be taking very little time, turn into hours of debates. If you have a good scrum master, perhaps this can be avoided, and it also depends on the overall personality of the team and individuals in the team. See http://www.scrumguides.org/

So in my experience, there is no one single methodology that one can simply adopt for the entire team. I believe it is the collective responsibility of the engineering leader and the team to craft the team’s own agile methodology by choosing the various best practices that are best suitable for the team, the product and the business. Each methodology comes with its own framework, values, practices and constraints. They are meant to provide guidance in determining your own successful course, and there is no need to be rigid about what you want to box yourself in. Make your own agile methodology by choosing the best of breed, blending with your own and team’s experience and skill set.

At any cost, do not forget the original purpose of your work, which is delivering high-quality software, and become a slave to the process. After all, delivering software is our business and we must enslave the process to do our bidding!