BOT – Do YOU Know How?

Today’s global economy is bridging the international gap and making many organizations who harness this change, very profitable. These organisations align themselves with the right providers at a macroeconomic level.

When companies grow, they look for ways to expand their existing operations to allow for increased throughput. The result is a careful balancing act between risk and reward.

There are numerous risks associated with expansion. An example of which, to expand through the conventional model, organizations must dedicate a portion (if not 100%) of existing skilled employee(s) to hiring and training all new recruits. This is a massive undertaking and does not factor in the likelihood of reduced output while this activity is in motion.

To reduce cost and risk, organizations turn to an offshore model where there is an abundance of human capital at reduced operational expenditures (OpEx). This is not straight forward as companies will then have to go through the lengthy, error-prone, and costly process of understanding how to find the right people, establish legal entities, and then operate under a different set of laws and customs.

The solution to this problem is a Build – Operate – Transfer model, or “BOT” for short.

Organizations leverage the BOT provider’s wealth of local knowledge to:

• Understand local laws, business environment and labor market;
• Attract, recruit, induct new skilled staff;
• Establish infrastructure; and
• Increase success percentage by utilizing the provider’s proven offshore methodology and practices.

Commercially, it makes sense by:

• Eliminating up-front Capital Expenditures (CapEx) involved with setting up a new office;
• Reducing time taken to become productive; and
• Reducing risk by providing an exit strategy to cancel the entire operation at short notice, reduce liquidating costs.

Now organizations have to find the right provider. It is absolutely critical to find the right provider that has the right expertise in delivering on BOT initiatives. I have personally witnessed many BOTs (some good, some bad) for almost a full decade now. Since 2005, I’ve been involved with internal BOT projects for a sizable company of 12,000 employees and $8.5B in annual revenues. Instead of a BOT with an offshore entity, we were building additional departments onshore which were later transitioned back into the business. In 2008, I lead the organization’s Transformation team which dedicated itself to building, operating and transferring functions back into the business. The year 2011 was a milestone year in terms of BOT velocity – we built a complete team of 55 employees in less than 6 months for an operator 13 time zones away!

All BOTs have their own unique traits but there are some commonalities. In an agreed time period, we BUILD up the platforms and solutions, OPERATE these for an agreed length of time – usually one or two years – to make sure all works seamlessly. Once the ters completes, all people, tools and processes are TRANSFERRED to the operator. This “expertise in a box” ensures operators can build up future-proof operations quickly and benefit from a pool of qualified resources who are trained and compliant in their existing mode of operation.

The fast pace environment of a BOT is very exciting and requires enormous dedication from the provider. The provider also has to be located in the correct geographic region to support the build. It is for these reasons that I truly believe Vinasource are uniquely positioned to be leaders in the BOT space.

Contact me today if you have any questions on BOTs and how they can help your organization.

Please check out my blog page at www.TimNguyen.ca to find out more information about myself.

Book Review – Predictable Revenue by Aaron Ross

Every now and then I come across a book that makes me go wow.  Predictable Revenue is one of them.

At some points the writing style seems a little choppy, but the message was pretty amazing.  Learn how a team of 1, completely changed how sales were being done for salesforce.com, ultimately building out a 12 person team that resulted in $100,000,000 a year in new sales.  And yes, that was recurring revenue!

It’s a fascinating story that tells of how Aaron went from CEO to Junior salesperson to someone who revolutionized how a billion dollar company manages their sales.

And yes, he does plug salesforce.com as a tool quite often!

Here is a quick summary of his methods:

Predictable Revenue is all about creating Predictable Lead Generation

First, get your team specialized by separating your sales group into the following roles:

• Sales Development – (Qualifiers)
• Account Executives – (Closers)
• Account Mangers – (Farmers)

Next, focus your Sales Development Team properly by doing the following:

• Ditch cold calls
• Invest real time in developing your target customer
• Invest more real time in researching and getting to the right people who work for your target customer
• Reach out using mass email in a simple format that is short, clear, honest and to the point.  The main point of the email is to ask a C level executive to point you to the right person in the company whom you should talk to about your product or service.  He said he was getting 7-10% response rates on this method!
• Call and build a relationship with that person by learning everything there is to know about the company.
• Qualify the lead based on key criteria.
• Pass the lead onto the Account Executives to close it
• Track metrics such as qualified leads per week, not things like calls and contacts

There is so much more to his methods and I highly encourage anyone developing a sales team to invest a few hours reading Predictable Revenue.  

Marketplaces – How to Grow Both Supply and Demand

With the trend of new marketplaces being created, and new sharing economy services launching, entrepreneurs often face the “chicken and the egg” problem – how to grow their user base on both the supply side and the demand side from zero.

Without density of supply in a marketplace, consumers won’t return since they won’t be able to find what they need frequently. Without density of demand in a marketplace, suppliers won’t return because their efforts yield few sales.

There are several approaches to consider, and some are more suited to certain verticals or markets. One interesting strategy might raise your eyebrows, but has been used very successfully. This approach is to “seed” supply and demand with external data or “orchestrated” activity, made by the company itself, to attract users. Take a look at this article for some good insights, explaining how others have applied this and how it can be applied to new businesses.

 

Is Your Startup Lean and Mean?

Reflecting back through all the learnings I’ve had in my involvement with the hundreds of projects we’ve completed at Vinasource, the most useful one is in appreciating and understanding the value of Lean Startup methodology and MVP products.

“Lean startup” is a method for developing businesses and product, originally proposed by Eric Ries in his appropriately named book, “The Lean startup“, The premise behind the methodology is that companies/startups spend too much time and money on product development before validating their core business and product models. Instead businesses should iteratively develop their product, continuously gathering customer feedback and validation, before further investing into deeper product features.

We’ve seen continuous validation in our own projects of the value of Lean Startup. The truth is, you just don’t KNOW, what the end user of your product really wants. Until you actually get actual customer validation, everything that you believe and are betting your company on is just a guess. Perhaps an educated guess, but truly still a guess. As such, developing a product is similar to the scientific method. Start with a hypothesis, perform an experiment to verify the hypotheses, and then analyze and perhaps refine your hypotheses based on data and learning.

Minimum Viable Product, or MVP, defines this process. The standard definition of MVP is a product that has “just the core features that allow the product to be deployed, and no more.” I actually prefer Ries’ deeper explanation that truly gets to the core purpose of MVP – “a version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

All of our projects at Vinasource start with an MVP, whether it ends up getting launched to the public or just shown to our customer for review and feedback. We help our clients whittle down their initial visions and requirements into an MVP, often cutting down months of development time and cost, with a goal of getting a working, usable, live initial version of the product up and running as soon as possible. The completion of the MVP doesn’t mean we’re necessarily “done” with the project, but it does mean that we have a working implementation that can be iterated upon. From there, depending on client preferences, the working product can be shown to early adopters, launched as a beta, or launched as an actual live V1 product itself. The feedback and usage data received from users at this point is often transformational. Features that were originally thought to be core to the product may turn out to be unused and ignored. Similarly, however, other features that perhaps barely even made it into the MVP are determined to be the most well-received features within the product and warrants further development and refinement.

A perfect example of this was in our own product, Anomo, an “anonymous social discovery” mobile application. Our check-in feature and “places” feature, which we spent the majority of our initial requirement/spec definition phase defining and perfecting, turned out to be a bit of a dud, due to the chicken-and-egg problem inherent in new social networks that haven’t yet achieved critical mass. On the other hand, our icebreakers feature turned out to be a massive hit, with over 500,000 questions answered per week. While this didn’t change our overall vision for the product, it did result in a pretty significant change in our philosophy, marketing, and advertising efforts for achieving critical mass.

The other key advantage that we found of the MVP model, particularly in being a services business, is that it allowed us to get an early checkpoint with our clients to ensure that we’ve all properly understood requirements and expectations. Inevitably, intent gets lost in communication. While the client may be describing a Volkswagon, we may have understood that they wanted a Ferrari (or vice versa). Nothing is more clear than working software. With the MVP, we can get initial client feedback, course correct if necessary, and ensure everybody is on the same page, before it’s too late.

Sometimes, MVP may actually mean not building a product at all! The famous example is of Nick Sinmurn, founder of Zappos. Instead of spending hundreds of thousands of dollars to build the perfect, beautiful, scalable, performant website, he first approached local shoe stores, took pictures of their inventory, posted pictures online, bought the shoes from stores at full price, and sold the shoes directly to customers from his rudimentary website at a loss. From that, he was able to establish demand and market fit, significantly reducing risk prior to further development and investment.

The natural tendency for entrepreneurs, particular those with high achieving academic and corporate backgrounds, is to seek perfection in their initial launch. Everything in their lives up to that point has validated their desire for perfection. But in a startup world of limited budget, limited time, and massive competition, building what you need, and ONLY what you need, is vital for survival. While it goes against every grain of your soul, Reid Hoffman’s (LinkedIn) famous quote – “if you are not embarrassed by the first version of your product, you’ve launched too late” (http://startupquote.com/post/855482768) is one at least worth considering.

Smart Start-Up Advice: 5 Steps for Effective Product Design

By Sven Larson –

A lot of products fail. And not just because of funding challenges or stiff competition.

Over and over, someone will have an idea for a product, spend a lot of time and money building out their vision and doing a big launch only to discover after a few weeks or months that no one actual buys or uses their product.

Essentially, they fail because the product is built based on the creator’s vision instead of solving for customer needs first.

Instead, it’s absolutely possible to be more aware during product development, arrive at a product design that people will actually want to use, and to save tens of thousands of dollars in the process.

I’ve studied and employed the Stanford Design Thinking approach to product design, and in my experience it cuts out the extraneous resource-wasting parts, and gets straight to the core of defining a product that will delight customers.

The Stanford approach consists of a cycle of five stages:

1.       Empathize – interview with two people from your team, observe person in their normal routine or context, making note of what they say and do.

2.       Define – in a group, unpack observations from interviews, interpret what they were thinking and feeling to determine main emotional drivers, and write/select a problem statement.

3.       Ideate – in a group, brainstorm ideas for solutions, following a specific brainstorming and focusing process.

4.       Prototype – in a group or individually create a low resolution prototype to use in the interview as a conversation piece.

5.       Test – interview (can be combined with #1), observing the person’s reaction to the prototype by what they say and do.

Stanford Design Thinking approach

To me, the biggest difference between this approach and others is observation at a very personal level, which is the “Empathy” stage. Many of the stages in this method are used in other design methods, but in this case they are combined and balanced in just the right way. This cyclic process also shares a lot with agile product development, mainly short iterations with feedback in each iteration, but the purpose and outcome here is not necessarily to end up with a functional prototype. The desired outcome is the description of a product that answers to the emotions of a small sampling of individuals who you have interviewed – maybe 3 to 8 people per cycle. Therefore, observing an individual in their regular day-to-day context to determine their emotional drivers is where this all begins. From my perspective, this is the biggest component lacking from the majority of product design today, and explains why there are so many products and features of products that just make you ask “what were they thinking?”

Keep in mind when studying this approach that we’re not talking about spending weeks building a prototype, then going out into the world and asking people “do you like this?” and “would you buy it?” This will cloud your customer observation, yield untrue answers, and mislead your product design. This applies especially during early phases of designing a new product, or designing a new feature of an existing product. Instead, you will be creating extremely “low resolution” or low-res prototypes. For a web site, this might mean a sharpie drawing on a piece of 8.5×11 paper. For a physical product, this might mean cardboard cutouts assembled with tape and rubber bands. It’s actually intentional to not have a polished mock-up or prototype initially, partly because it will get you more honest feedback when you place it in front of someone – they’re not afraid to be blunt. Instead if you put a highly polished prototype in front of someone, they will likely be thinking “well, it looks like they put a lot of time and money into this, so they must know what they’re doing, and I don’t want to hurt their feelings either.”

The other key thing you’ll have to accept is that your product is going to have to evolve during this design process – possibly pretty radically. You won’t – and shouldn’t – end up with what you originally envisioned. Every iteration you run through, you should have at least a slightly different product definition. If you’ve been through several iterations and there’s been no change, you should question whether it’s time to move on to creating a more functional prototype because you’ve done such a good job of product design up to this point and you feel the definition has stabilized, or whether you should go back and review the guidelines of the Stanford approach to see what’s causing stagnation. Either way, I’d expect to go through at least 5 to 10 (or better yet – 15 to 20) iterations before starting to feel comfortable enough to invest dollars in creating a functional prototype.

The great thing is there’s a ton of material freely available online on the d.school web site that guides you through this in detail. I’d specifically recommend checking out the downloadable PDF called “The Bootcamp Bootleg” here. There are also videos and resources to run your own course for others on your team. Of course, you don’t have to follow their guidelines exactly – you should adapt to your organization – but it’s worth following the five steps, and learning their approach for each step to choose which pieces work well for you.

It’s extremely exciting to realize that with each iteration, your design is actually becoming a more and more useful product, and that you’re saving a large amount of time and money by waiting to implement until you have really vetted the design. I’m always hopeful that more and more companies will follow this approach. It’s the natural evolution of things.