Thursday, December 19, 2013

B2B Go-to-Market Strategy

Your B2B application will transform the business world… once it's in the right hands. All you have to do now is find those hands and get your application into them — but how? There are two key approaches: you can either target business clients directly or you can go through channel partners who will sell your product and/or service to your B2B clients. Both approaches have benefits and limitations.

Going to market direct gives you much more control over the sales process, from deciding how the offering should be branded and positioned to choosing how to close the deal. This approach enables you to develop close relationships with your customers; to learn about their needs and address them at first hand. The disadvantage, however, is that your rate of new deals is in direct proportion to your available sales resources. Optimizing your offering for self-service sale might help, but generally, to be successful, a B2B sale requires that human touch.

On the other hand, the channel partner strategy will enable you to leverage your sales resources to land more channel partners who will then pursue the end-user clients. While it may take longer to get a partner empowered to sell, when executed successfully, this method allows you to grow your client base faster while leveraging the same sales resources. Channel partners may be regional, national, or global players with well-established client bases to whom they can offer your product or service. Additionally, when exploring new geographic or product domains, channel partners with specific or local expertise can provide guidance and reduce the inherent risk of venturing into new territory.

However, going to market through channel partners can lead to a certain loss of control over branding and positioning. It may also hinder the development of direct relationships with the people who actually use your offering, ultimately denying you a direct insight into your clients’ needs. Moreover, if the product is particularly complex, it can take partners a long time to get up to speed and ready to sell. And, on top of all that, the infrastructure and costs required to compensate your channel partners will lower your margins.

A combination of both approaches can help to manage the limitations, but you will have to take a number of decisions about things like how to manage incentives for your sales team and how to resolve conflicts between your direct and your channel sales. The latter can be tackled by establishing clear distinctions between the product types, branding, positioning, target client sizes and sales territories that these two go-to-market strategies will use. Most importantly, internal and external transparency and fairness throughout the entire process will go a long way towards creating good will for all concerned, at whichever end of the rainbow they find themselves.

Rachel, Daniil, and Dmitry

Thursday, December 12, 2013

Iceberg Effect in Software Development

The iceberg effect… That’s what happens when you start to build a software application around that hot prototype your investors were so excited about. You’ll soon discover that only about 10% of your application is visible to the users, while the other 90% is hidden below the surface, preventing you from rolling it out and starting to rake in the revenue. The truth of the matter is that every application has infrastructure, and while the need for certain components may be obvious, there will be a number of slap-on-the-forehead moments before they’re discovered, and all of them have to be implemented.

The iceberg effect is particularly noticeable when you work with applications targeted towards business consumers. One of the first areas you’ll have to address is security, which includes not only accommodating different types of business users but also incorporating protection from external vulnerabilities such as backdoors, SQL injection, cross site scripting and more, which brings up one of the core components - data. Data has to be exported, imported, audited, stored, and managed; thus bringing up visual interfaces, monitoring, alerts, and so on.

As you’re scrambling to close the gaps as quickly as possible your clients drop in to see how it’s going and suggest a couple of “minor” modifications that require you to completely re-factor your established paradigms. And, while you are at it, don’t forget to address the back-end infrastructures to support report generation, database connectivity, error logging, notifications, and all the other things that seem to arrive with every new day – to the point where you find yourself forgetting about the application you originally wanted to write.

The situation may not seem so dire because there are tools/libraries available to help with a good number of things. Yet, each component will need to be identified, evaluated, integrated, and tested to play nicely with the others. Each addition will introduce new risks to security, performance, and scalability. In the very likely event that more than one developer is working on the project, you’ll have to contend with different approaches to programming as well as different development choices driven by different assumptions. In the end you’ll find yourself taking the system apart and putting it back together again on an almost daily basis.

If you run a SaaS shop, the good news is you won’t need to ask your precious-yet-scant clientele to re-install an updated version every couple of days. The bad news, if you run a SaaS shop, your precious-yet-scant clientele will be privy to most of the excitement firsthand, every couple of days. This is probably a good time to be on the lookout for sociopathic behavior from the CEO and fledging sales staff.

To sum up this little horror story, that’s what software icebergs are all about. Do not despair. Stay tuned.

Dmitry, Daniil, & Rachel

Thursday, December 5, 2013

Meaningless Meetings

Have you ever wondered how much of your (working) life has been spent in meetings? Neither had we, until we met to discuss this article. After an animated debate, the consensus was that the human ability to multi-task probably evolved as a result of being stuck in too many gatherings, forced to feign interest and nod knowingly at the words of chieftains, shamans, professional meeting-junkies, and remote employees allowed on site to drivel on and on incessantly for hours and hours on end about nothing in particular. For those of us who can engage ourselves in scribbling, furtive email checking, or surreptitious abdominal crunches, a boring meeting can often be transformed into a partial, rather than a complete, waste of time.

But human beings are social creatures. They need to communicate to be happy and, in a company setting, they need to meet to agree on what to do and how to do it. So, what can be done to optimize these exchanges to ensure that they don’t become an all-consuming force sucking all the useful hours out of the day?

First and foremost, expectancies should be set. What do you and your fellow participants hope to get out of this meeting (apart from getting out of the meeting)? This includes some thought into expected participants, pre-requisite information required before the meeting, topics to be discussed, and some initial expectation of the end results/actions. The format of the meeting and communication media should also be considered. Can the goals be met “offline?” If so, maybe you don’t need a meeting after all! If it is unavoidable, then start building up and sharing those expectations in advance. Doing this will go a long way towards ensuring a productive experience for all concerned.

This doesn’t happen spontaneously; it takes some work, which may explain why managers sometimes end up taking the easy route by “just getting everyone into the room.” The frustrating thing about this is that a) it takes forever to get together – not least because everyone is attending other important meetings; and b) participants often arrive absolutely clueless about why they are there. Thus they can barely contribute anything at all, let alone constructive input. The result is that it takes a painfully long time to reach agreement and take important decisions. To get the most out of a meeting, the moderator should keep track of the discussion and action items. If the conversation starts to drift away from point or someone monopolizes the airtime, it is for the moderator to decide whether it’s better to refocus the audience or to continue exploring the new direction. We found it helpful to document teams’ regular meetings discussion topics and action items for the updates as needed.

Speaking of regular meetings that seem to be scheduled to run into infinity: while they can work great at ensuring consistent practices, some of them outgrow their purpose and become events in which fewer and fewer participants actually participate; fed up of constantly reporting, “Nothing to report.” These meetings do suit some people, however, because they fill up the calendar and make everyone appear “busy”.

There are a few exceptions. Executive team members should try to meet regularly and often, regardless of agenda. Running a company is a bit like being in a marriage: if you don’t see each other often enough, you start to grow apart. Additionally, if there is an emergency that warrants a quick huddle, it’s insane to wait. There should be meetings scheduled to share official news (also communicated in-writing). And, finally, team members should have the opportunity to connect simply to enjoy each other’s company. This could be in the break room catching lunch together or at the ping pong table. We’ll never get rid of all those “meaningless” meetings, but maybe they will be fewer in number and much less meaningless.

Rachel, Daniil, & Dmitry

Thursday, November 21, 2013

Hire bright and hungry

In order to build a great organization you’ve got to hire great people. But recognizing a great person when you meet one isn’t that easy. After getting burned a couple of times, we realized how devastating a poor hiring choice can be.

The following phrase from Demotivators puts it particularly well: “A few harmless flakes working together can unleash an avalanche of destruction.” From work done poorly to work not done at all, the snowball effect of a bad hiring decision will impact on office morale, lead to falling productivity, declining standards of service and ultimately tarnish a company’s hard-earned reputation.

While small businesses tend to be worse hit by poor hiring, large organizations are not immune. Yahoo! is a prime example of what can happen when an organization grows too big and when not everyone on the bus is going in the right direction. In Yahoo’s case, hundreds of under-performing “passengers” will be told to “get out and walk”.

We realized we weren’t alone in facing this “Mary Poppins” challenge. Fortunately, there are plenty of resources available to help everyone with their difficult hiring decisions. Based on the advice given and our own experience, we identified three key attributes an applicant should possess in order to increase our chances of successful hire.

Firstly, they should be bright. They may not know everything, but if they’re bright, they’ll be eager to learn and if they’re hungry (driven) as well, they’ll be doubly so. Hunger is the second of our attributes. Seek out people with ambition and a plan of action; it doesn’t matter whether they plan to learn something or to help someone as long as they are driven.

And finally, the thing that separates the true stars from the rest of us is a special “something” in their character that makes them particularly well-suited to a particular position. For example, if you’re looking for an accountant, look for someone who’s got a passion for detail – someone who insists on taking that second look at that invoice before firing it off to the client. Admittedly, it’s not every day that we bump in stars such as these, but at least it’s good to know we’ll recognize them when we do.

Whether someone is bright or not, or whether they have a particular aptitude for a job, can be determined quite easily in an interview. “Drive” however is a “moving target” that’s more challenging to pinpoint. You really have to strive to understand exactly what motivates a person. Perhaps there are people in your company who are able bring out this kind of information from job applicants.

The important thing is to come up with a process that fits your needs and then apply it consistently with every applicant, no matter how impressive their resume or how charming they are in person. As your team gets larger and as you delegate this important responsibility to other team members…. But that’s another posting.

Rachel, Dmitry & Daniil

Wednesday, November 13, 2013

Technical decisions taken by committee do not always work

Collaborative decision-making in commercial software projects is liable to lead technical teams awry. Heretical as this may sound – and before the mob of inclusive development zealots cast their collective stones –  please allow us one moment to explain our point of view, based as it is on our own experiences.

Creating complex software systems is a game of tradeoffs. To use an automotive analogy, you can’t design a car with the performance of a Ferrari and the hauling power of a Chevy truck for the price of a Honda Civic – you have to strike a balance. Likewise with software development: technical decisions call for technical tradeoffs.

Collaboration provides valuable perspectives and innovative insights into technical problems, but when it’s time for big decisions, the best you get is a compromise, which may not be the right decision.  Although collaborative tools and best practices make it easier for people to work together, they fall short of addressing the individual and social factors that each person brings to the table. Suggestions made by team members may be influenced by personal preferences, experiences, and agendas: job security, resistance to change, procrastination, ambition, competitiveness, groupthink, insecurity, showiness, politics and more.

A true techie is a complex creature – part scientist, part artist – for whom software development is a calling, a passion, a way of life. It’s little wonder then that they tend to bring more baggage than most to the table. We’ve dealt with countless examples of pride in job ownership that have stretched the bounds of reason. In one instance, persuading the party in question to relinquish their code for the sake of stability, scalability and all the rest of it was akin to asking them to sacrifice their firstborn, so we gave up, against our better judgment. We watched the entire team wasting valuable time adapting to this doomed branch of the evolutionary code tree only to make someone else feel good. A few weeks later, when the dust had settled, it became apparent to everyone that we’d reached a dead-end; we had to throw out months of hard work and start from scratch.

At the other extreme, the desire to incorporate every single item of new technology that comes along can result in the creation of Frankenstein monsters, prone to crash and burn at any moment. This gives the ultimate thrill to the business side: it’s cool to be on the cutting edge, as long as you don’t fall off.  When you’re trying to design software to be as lean as possible, the indiscriminate addition of new technologies is unlikely to do you any favors. And worse still, unproven software can conflict with existing pieces and lead to more serious problems.

To sum up, too much democracy can result in consensus-based decision making that is detrimental to the rapid development of scalable commercial systems. In our experience, having one person taking ultimate responsibility significantly speeds up the decision making process, reduces the risk of analysis paralysis, and allows decision making to remain consistent with the company’s central vision. The individual responsible also has the power of veto on questions of adopting new technologies or abandoning ideas that obviously have no hope of getting off the ground.

The person taking on these responsibilities must be inclusive; they must set expectations clearly within the team and be able to tap into the members’ knowledge and expertise, which they should choose and use on its merit. The individual should provide encouragement and overall guidance rather than finely-tuned micro management, acting as a catalyst and a conduit for the flow of ideas and swift decisions. We never said it would be easy!  

Although collaborative decision making can and does work well in a number of settings, we found that in the context of large commercial systems the ability to make fast consistent decisions stands an equal if not superior chance of yielding the desired results.