Saturday, December 21, 2013
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
Tuesday, December 10, 2013
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
Wednesday, December 4, 2013
Subscribe to:
Posts (Atom)