摩纳哥|官方

    1. <small id="oemes"><strong id="oemes"></strong></small>
        <meter id="oemes"><delect id="oemes"></delect></meter>
        <mark id="oemes"></mark>
              <meter id="oemes"><strong id="oemes"></strong></meter>
              
              
              <mark id="oemes"></mark>

              <input id="oemes"></input>
              <menu id="oemes"><u id="oemes"></u></menu>
            1. Showing posts with label platform. Show all posts
              Showing posts with label platform. Show all posts

              Tuesday, October 21, 2014

              Disruptive Enterprise Platform Sales: Why Buy Anything, Buy Mine, Buy Now - Part III


              This is the third and the last post in the three-post series on challenges associated with sales of disruptive platforms such as Big Data and how you can effectively work with your prospects and others to mitigate them. If you missed the previous posts the first post was about “why buy anything” and the second post was about “why buy mine." This post is about “why buy now."

              Platform sales is often times perceived as a solution looking for a problem a.k.a hammer looking for a nail. In most cases your prospects don’t have a real urgency to buy your platform making it difficult for you to make them commit on an opportunity. There are a few things that you could do to deal with this situation:

              Specific business case

              It’s typical for vendors to create a business case positioning their solutions to their prospects. These business cases include details such as solution summary, pricing, ROI etc. If you’re a platform vendor not only you have to create this basic business case but you will also have to go beyond that. It’s relatively hard to quantify ROI of a platform since it doesn’t solve a specific problem but it could solve many problems. It is extremely difficult to quantify the impact of lost opportunities. If your prospect doesn’t buy anything do they lose money on lost opportunities? Traditional NPV kind of analysis goes for a toss for such situations.

              As a vendor not only you will have to articulate the problems (scenarios/use cases) that you identified leading up to this step but you might also have to include more scenarios that were not specifically discussed during the evaluation phase. Getting a validation from the business on expected return on their investment while fulfilling their vision is crucial since your numbers will most likely get challenged when your prospect creates its own business case to secure necessary investment to buy your platform.

              Leveraging the excitement

              What seemed like a problem when you worked with a variety of people inside your prospect’s organization may not seem like a problem in a few weeks or months. It’s very important in platform sales cycle not to lose momentum. Find a champion of your pilot keep socializing the potential of your platform inside your prospect’s organization as much as you can while you work on commercials of your opportunity. People should be talking about your disruptive platform and wanting to work with you. Cease that moment to close it.

              Knowing who will sign the check

              Platform sales are convoluted. People who helped you so far may not necessarily help you with the last step—not that they don’t want to but they may not be the buyers who will sign the check. It’s not uncommon in enterprise software sales to have influencers who are not the final buyers but the buyers do have somewhat defined procurement process for standard solutions. When it comes to buying a platform many buyers don’t quite understand why they should be spending money on disruptive platform that may or may not necessarily solve a specific problem.

              To complicate this further, for disruptive technology, it typically tends to get cheaper as it becomes more mature. This gives your prospect one more reason to wait and not buy your platform now. As I mentioned in the previous post your focus should never be on pricing (unless of course you are the best and cheapest vendor by a wide margin) but on immediate returns, no lost opportunities, and helping your prospect gain competitive differentiation in their industry.

              Despite of working with your prospect for a while helping them define problems and piloting your platform to prove out the value proposition, you might get asked again to do things all over again. There are two ways to mitigate this situation: a) involve buyers early on in the sales process and not at the very end so that they are part of the journey b) work aggressively with your influencers to establish appropriate communication channels with the buyers so that it’s the influencer’s voice they hear and not yours.

              Happy selling!

              Photo Courtesy: Wierts Sebastien  

              Monday, September 22, 2014

              Disruptive Enterprise Platform Sales: Why Buy Anything, Buy Mine, Buy Now - Part II


              This is the second post in the three-post series on challenges associated with sales of disruptive platforms such as Big Data and how you can effectively work with your prospects and others to mitigate them. If you missed the first post in the series it was about “why buy anything.” This post is about “why buy mine."

              Convincing  your prospects they need to buy a platform is just a first step in the sales process. You need to work with them to convince them to buy not just any platform but your platform.

              Asking the right questions - empathy for business

              This is the next logical step after you have managed to generate organic demand in your prospect’s organization a.k.a “why buy anything” as I mentioned in the Part I. Unlike applications, platforms don’t answer a specific set of questions (functional requirements). You can’t really position and demonstrate the power of your platform unless you truly understand what questions your prospect needs you to answer. Understanding your prospect’s questions would mean working closely with them to understand their business and their latent needs. Your prospect may or may not tell you what they might want to do with your platform. You will need to do it for them. You will have to orchestrate those strategic conversations that have investment legs and understand problems that are not solvable by standard off-the-shelf solutions your prospect may have access to.

              Answering the right questions - seeing is believing

              One of the key benefits of SaaS solutions is your prospect’s ability to test drive your software before they buy it. Platforms, on-premise or SaaS, need to follow the same approach. There are two ways to do this: you either give your prospect access to your platform and let them test drive it or you work with your prospect and be involved in guiding them through how a pilot can answer their questions and track their progress. While the latter approach is a hi-touch sale I would advise you to practice it if it fits your cost structure. More on why it is necessary to stay involved during the pilot in the next and the last post (Part III) in this series.

              Proving unique differentiation

              Once your prospect starts the evaluation process whether to buy your platform or not your platform will be compared with your competitive products as part of their due diligence efforts. This is where you want to avoid an apple-to-apple comparison and focus on unique differentiation.

              Even though enterprise platform deals are rarely won on price alone don’t try to sell something that solves a problem your competitors can solve at the same or cheaper price. Don’t compete on price unless you are significantly cheaper than your competitor. The best way to position your platform is to demonstrate a few unique features of your platform that are absolutely important to solve the core problems of your prospect and are not just nice-to-have features.

              Care deeply for what your prospects truly care about and prove you’re unique.

              The next and the last post in this series will be about “why buy now.”

              Photo courtesy: Flickr 

              Sunday, August 31, 2014

              Disruptive Enterprise Platform Sales: Why Buy Anything, Buy Mine, Buy Now - Part I


              I think of enterprise software into two broad categories - products or solutions and platform. The simplest definition of platform is you use that to make a solution that you need. While largely I have been a product person I have had significant exposure to enterprise platform sales process. I have worked with many sales leaders, influencers, and buyers. Whether you're a product person or you're in a role where you facilitate sales I hope this post will give you some insights as well as food for thought on challenges associated with sales of disruptive platforms such as Big Data and how you can effectively work with customers and others to mitigate some of these challenges.

              I like Mark Suster's sales advice to entrepreneurs through his framework of "why buy anything", why buy mine", and "why buy now." I am going to use the same framework. Platform sales is sales in the end and all the sales rules as well as tips and tricks you know that would still apply. The objective here is to focus on how disruptive enterprise software platform sales is different and what you could do about it.

              The first part of this three-post series focuses on "why buy anything."

              Companies look for solutions for problems they know exist. Not having a platform is typically not considered a good-enough problem to go and buy something. IT departments also tend to use what they have in terms of tools and technology to solve problems for which they decide to "build" as opposed to "buy." Making your prospects realize they need to buy something is a very important first step in sales process.

              Generating organic demand:

              Hopefully, you have good marketing people that are generating enough demand and interest in your platform and the category it belongs to. But, unfortunately, even if you have great marketing people it won't be sufficient to generate organic demand for a platform with your prospect. When it comes to platform sales your job is to create organic demand before you can fulfill it. This is hard and it doesn't come naturally to many good sales people that I have known. By and large sales people are good at three things: i) listen: understand what customers want ii) orchestrate: work with a variety of people to demonstrate that their product is the best feature and price fit iii) close: identify right influencers and work with a buyer to close an opportunity. While platform sales does require these three qualities like any other sales creating demand or appetite is the one that a very few sales people have. You have to go beyond what your prospects tell you; you have to assess their latent needs. Your prospects won't tell you they need a disruptive platform simply because they don't know that.

              You're assuming a 1-1 marketing role to create this desire. Connect your prospects with (non-sales) thought leaders inside as well as outside of your organization and invite them to industry conferences to educate them on the category to which your platform belongs to. Platform conversations, in most cases, start from unusual places inside your prospect's organization. People who are seen as technology thought leaders or are responsible for "labs" inside their company or people who self-select as nerds or tinkerers are the ones you need to evangelize to and win over. These people typically don't sit in the traditional IT organization that you know of and even if they do they are not the ones who make decisions. These folks are simply passionate people who love working on disruptive technology and have a good handle on some of the challenges their companies are facing.

              Dance with the business and the IT:

              As counterintuitive as it may sound working with non-IT people to sell technology platform to IT is a good way to go. The "business" is always problem-centric and the IT is always solution-centric. Remember, you're chasing a problem and not a solution. Identify a few folks in a line of business who are willingly to work with you. This is not easy especially if you're a technology-only vendor. Identify their strategic challenges that have legs — money attached to it. Evangelize these challenges with IT to generate interest in disruptive platform that could be a good fit for these challenges.

              IT doesn't like disruption regardless of what they tell you. If they are buying your disruptive platform they are not buying something else and they don't use some of the existing platforms or tools they have. There are people who have built their careers building solutions on top of existing tools and technology and they simply don't want to see that go away. You will have to walk this fine line and get these people excited on a new platform that doesn't threaten their jobs and perhaps show them how their personal careers could accelerate if they get on to this emerging technology that a very few people know in the company but something which is seen highly strategic in the market. Don't bypass IT; it won't work. Make them your friends and give them an opportunity to shine in front of business and give them credit for all the work.

              Chasing the right IT spend:

              Most enterprise software sales people generally know two things about their customers: i) overall IT spend ii) how much of that they spend with you. What they typically don't know is how much a customer spends on similar technology or platforms from that overall IT spend that doesn't come your way. There are two ways to execute a sales opportunity: either you find something to sell for the amount that your customer typically spends with you on annual basis or you go after the larger IT spend and expand your share of the overall pie. It's the latter that is relevant when you're selling platform to your existing customer (and not a prospect).

              Platform, in most cases, is a budgeted investment that falls under "innovation" or "modernization" category. If you're just focused on current spending pattern of your customer you may not be able to generate demand for your platform. It is your job to convince your customer to look beyond how they see you as a vendor and be open to invest into a category that they might be reluctant for.

              The next post in this series will be about "why buy mine."

              Photo courtesy: Stef

              Friday, December 17, 2010

              Salesforce.com's $212 Million Acquisition of Heorku - A Sparkling Gem In Radiant Future Of Cloud And PaaS

              I met James Lindenbaum, a founder of Heroku, in early 2009, at the Under The Radar conference in Mountain View. We had a long conversation on cloud as a great platform for Ruby, why Ruby on Rails is a better framework than PHP, and viability of PaaS as a business model. He also explained to me why he chose to work on Heroku at Y Combinator. I was sold on their future, on that day, and kept in touch with them since then. The last week, Salesforce.com acquired Heroku for $212 million. That's one successful exit, which is good news in many different dimensions.

              PaaS is a viable business model

              PaaS is not easy. It takes time, laser sharp focus, and hard work to build something that the developers would use and pay for. A few companies have tried and many have failed. But, it is refreshing to see the platform and the ecosystem that Heroku has built since its inception. Heroku did not raise a lot of money, kept the cost low, and attracted customers early on. I was told (by Byron, I think) that an average cost for Heroku to run a free Ruby app for a month was $1. They considered it as marketing cost to get new customers and convert the free customers to paying ones, as they outgrew their needs. I cannot overpraise this brilliant execution model. I hope to see more and more entrepreneurs being inspired from - simplicity, elegance, and execution of Heroku's model - to help the developers deploy, run, and scale their applications on the cloud. In the last few years, we have seen a great deal of innovation in dynamic programming languages, access algorithms, and NoSQL persistence stores. They all require a PaaS that the developers can rely on - without worrying about the underlying nuts and bolts - and focus on what they are good at - building great applications. If anyone had the slightest doubt on viability of PaaS as a business model, this acquisition is a proof point that PaaS is indeed the future. Heroku is just the beginning and I am hoping for more and more horizontal as well as vertical PaaS that the entrepreneurs will aspire to build.

              Superangels and incubators do work

              There have been many debates on viability of the investing approach of the superangels and the incubators, where people are questioning, whether the approach of thin slicing the investment, by investing into tens and hundreds of companies, would yield similar returns, as compared to return on traditional venture capital investment. I also blogged about the imminent change in the VC climate, and decided to watch their returns. The numbers are in with Heroku. It's a first proof point that a superangel or an incubator approach, structurally, does not limit the return on the investment. I believe in investors investing in right people solving the right problems. If you ever meet James and hear him passionately talk about Ruby, the Heroku platform, and the developer community, you will quickly find out why they were successful. Hats off to YC on finding this "jewel". No such thing as too little investment, or too many companies.

              Ruby goes enterprise

              I know many large ISVs that have been experimenting with Ruby for a while, but typically these efforts are confined to a few small projects. It's good to see that Ruby, now, has a shot of getting much broader adoption. This would mean more developers learning Ruby, cranking out great enterprise gems, embracing Git, and hopefully open source some of their work. I have had many religious discussions, with a few cloud thought leaders and bloggers in the past few months, regarding the boundaries of PaaS. The boundaries have always been blurry - somewhere between SaaS and IaaS - but, I don't care. My heart is at delivering the applications off the cloud that scales, delivers compelling experiences, and leverages economies of scale and network effects. To me, PaaS is means to an end and not the end. I am hoping that an acquisition of a PaaS vendor by a successful SaaS vendor will make Ruby more attractive to enterprise ISVs and non-Ruby developers.

              I have no specific insights into what Salesforce.com will do with Heroku, but I hope, they make a good home for Heroku, where they flourish and continue to do great work on Ruby and PaaS. This is what a cloud and Ruby enthusiast would wish for.

              Monday, July 21, 2008

              SaaS platform pitfalls and strategy - Part 2

              In part 1, I discussed my views on the top 10 mistakes that vendors make while designing a SaaS platform as described in the post at GigaOM. This post, the part 2, has my strategic recommendations to SaaS vendors on some of the important topics that are typically excluded from the overall platform strategy.

              Don't simply reduce TCO, increase ROI: According to an enterprise customer survey carried out by McKinsey and SandHill this year, the buying centers for SaaS are expected to shift towards the business with less and less IT involvement. A SaaS vendor should design a platform that not only responds to the changing and evolving business needs of a customer but can also adapt to changing macro-economic climate to server customer better. Similarly a vendor should carve out a Go To Market strategy targeting the businesses to demonstrate increased ROI and not necessarily just reduced TCO even if they are used selling a highly technical component to IT.

              The Long Tail
              : SaaS approach enables a vendor to up-sell a solution to existing customers that is just a click-away and does not require any implementation efforts. A vendor should design a platform that can identify the customer's ongoing needs based on the current information consumption, usage, and challenges and tap into a recommendation engine to up-sell them. A well-designed platform should allow vendors to keep upgrade simple, customers happy, and users delighted.

              Hybrid deployment: The world is not black and white for the customers; the deployment landscape is almost never SaaS only or on-premise only. The customers almost always end up with a hybrid approach. A SaaS platform should support the integration scenarios that spans across SaaS to on-premise. This is easier said than done but if done correctly SaaS can start replacing many on-premise applications by providing superior (non)ownership experience. A typical integration scenario could be a recruitment process that an applicant begins outside of a firewall on a SaaS application and the process gradually moves that information into an enterprise application behind the firewall to complete the new hire workflow and provision an employee into the system. Another scenario could be to process a lead-to-order on SaaS and order-to-cash on on-premise.

              Ability to connect to other platforms: It would be a dire mistake to assume standalone existence of any platform. Any and all platforms should have open, flexible, and high performance interfaces to connect to other platforms. Traditionally the other platforms included standard enterprise software platforms but now there is a proliferation in the social network platforms and a successful SaaS player would be the one who can tap into such organically growing social networking platforms. The participants of these platforms are the connectors for an organization that could speed up cross-organizational SaaS adoption across silos that have been traditional on-premise consumers.

              Built for change: Rarely a platform is designed that can predict the technical, functional, and business impact when a new feature is included or an existing feature is discarded. Take internationalization (i18n) as an example. The challenges associated to support i18n are not necessarily the resources or money required to translate the content into many languages (Facebook crowdsourced it) but to design platform capabilities that can manage content in multiple languages efficiently. Many platform vendors make a conscious choice (rightfully so) not to support i18n in early versions of the platform. However rarely an architect designs the current platform that can be changed predictably in the future to include a feature that was omitted. The design of a platform for current requirements and a design for the future requirements are not mutually exclusive and a good architect should be able to draw a continuum that has change predictability.

              Virtualize everything: Virtualization can insulate a platform from ever-changing delivery options and allow vendors to focus on the core to deliver value to the applications built on the platform. A platform should not be married to a specific deployment option. For instance a vendor should be able to take the platform off Amazon's cloud and put it on a different cluster without significant efforts and disruptions. The trends such as cloud computing have not yet hit the point of inflection and the deployment options will keep changing and the vendors should pay close attention to the maturity curve and hype cycle and make intelligent choices that are based on calculated risk.

              Vendors should also virtualize the core components of the platform such as multi-tenancy and not just limit their virtualization efforts to the deployment options. Multi-tenancy can be designed in many different ways at each layer such as partitioning the database, shared-nothing clusters etc. The risks and benefits of these approaches to achieve non-functional characteristics such as scalability, performance, isolation etc. change over a period of time. Virtualizing the multi-tenancy allows a vendor to manage the implementation, deployment, and management of a platform independent of constantly moving building components and hence guarantee the non-functional characteristics.

              Don't bypass IT: Instead make friends with them and empower them to server users better. Even if IT may not influence many SaaS purchase decisions IT is politically well-connected and powerful organization that can help vendors in many ways. Give IT what they really want in a platform such as security, standardization, and easy administration and make them mavens of your products and platform.

              Platform for participation: Opening up a platform to the ecosystem should not be an afterthought instead it should be a core strategy to platform development and consumption. In early years eBay charged the developers to use their API and that inhibited the growth which later forced eBay to make it free and that decision helped eBay grow exponentially. I would even suggest to open source few components of the platform and also allow developers to use the platform the way they want without SaaS being the only deployment option.

              Platform Agnostic: The programming languages, hardware and deployment options, and UI frameworks have been changing every few years. A true SaaS platform should be agnostic to these building components and provide many upstream and downstream alternatives to build applications and serve customers. This may sound obvious but vendors do fall into "cool technology" trap and that devalues the platform over a period of time due to inflexibility to adopt to changing technology landscape

              Monday, July 7, 2008

              SaaS platform - design and architecture pitfalls - Part 1

              I cannot overemphasize how critical it is to get the SaaS platform design right upfront. GigaOM has a post that describes the top 10 mistakes that vendors make while designing a SaaS platform. I would argue that many of these mistakes are not specific to a SaaS platform but any platform. I agree with most of the mistakes and recommendations, however I have quite the opposite thoughts about the rest. I also took an opportunity to think about some of the design and architectural must have characteristics of a SaaS platform that I will describe in the part 2 of this post.

              1) Failing to design for rollback

              "...you can only make one tweak to your current process, make it so that you can always roll back any code changes..."

              This is a universal truth for any design decision for a platform irrespective of the delivery model, SaaS or on-premise. eBay makes it a good case study to understand the code change management process called "trains" that can track down code in a production system for a specific defect and can roll back only those changes. A philosophical mantra for the architects and developers would be not to make any decisions that are irreversible. Framing it positively prototype as fast as you can, fail early and often, and don't go for a big bang design that you cannot reverse. Eventually the cumulative efforts would lead you to a sound and sustainable design.

              2) Confusing product release with product success

              "...Do you have “release” parties? Don’t — you are sending your team the wrong message. A release has little to do with creating shareholder value..."

              I would not go to the extreme of celebrating only customer success and not release milestones. Product development folks do work hard towards a release and a celebration is a sense of accomplishment and a motivational factor that has indirect shareholder value. I would instead suggest a cross-functional celebration. Invite the sales and marketing people to the release party. This helps create empathy for the people in the field that developers and architects never or rarely meet and this could also be an opportunity for the people in the field to mingle, discuss, and channel customer's perspective. Similarly include non-field people while celebrating field success. This helps developers, architects, and product managers understand their impact on the business and an opportunity to get to know who actually bought and started using their products.

              5) Scaling through third parties

              "....If you’re a hyper-growth SaaS site, you don’t want to be locked into a vendor for your future business viability..."

              I would argue otherwise. A SaaS vendor or any other platform vendor should really focus on their core competencies and rely on third parties for everything that is non-core.

              "Define how your platform scales through your efforts, not through the systems that a third-party vendor provides."

              This is partially true. SaaS vendors do want to use Linux, Apache, or JBoss and still be able to describe the scalability of a platform in the context of these external components (that are open source in this case). The partial truth is you still can use the right components the wrong way and not scale. My recommendation to a platform vendor would be to be open and tell their customers why and how they are using the third party components and how it helps them (the vendor) to focus on their core and hence helps customers get the best out of their platform. A platform vendor should share the best practices and gather feedback from customers and peers to improve their own processes and platform and pass it on to third parties to improve their components.

              6) Relying on QA to find your mistakes:

              "QA is a risk mitigation function and it should be treated as such"

              The QA function has always been underrated and misunderstood. QA's role extends way beyond risk mitigation. You can only fix defects that you can find and yes I agree that mathematically it is impossible to find all the defects. That's exactly why we need QA people. The smart and well-trained QA people think differently and find defects that developers would have never imagined. The QA people don't have any code affinity and selection bias and hence they can test for all kinds of conditions that otherwise would have been missed out. Though I do agree that the developers should put themselves in the shoes of the QA people and make sure that they rigorously test their code, run automated unit tests, and code coverage tools and not just rely on QA people to find defects.

              8) Not taking into account the multiplicative effect of failure:

              "Eliminate synchronous calls wherever possible and create fault-isolative architectures to help you identify problems quickly."


              No synchronous calls and swimlane architecture are great concepts but a vendor should really focus on automated recovery and self-healing and not just failure detection. A failure detection could help vendor isolate a problem and help mitigate the overall impact of that failure on the system but for a competitive SaaS vendor that's not good enough. Lowering MTBF is certainly important but lowering MDT (Mean down time) is even more important. A vendor should design a platform based on some of the autonomic computing fundamentals.

              10) Not having a business continuity/disaster recovery plan:

              "Even worse is not having a disaster recovery plan, which outlines how you will restore your site in the event a disaster shuts down a critical piece of your infrastructure, such as your collocation facility or connectivity provider."

              Having a disaster plan is like posting a sign by an elevator instructing people not to use it when there is a fire. Any disaster recovery plan is, well, just a plan unless it is regularly tested, evaluated, and refined. Fire drills and post-drill debriefs are a must-have.

              I will describe some of the design and architectural must have characteristics of a SaaS platform in the part 2 of this post.
              1. <small id="oemes"><strong id="oemes"></strong></small>
                  <meter id="oemes"><delect id="oemes"></delect></meter>
                  <mark id="oemes"></mark>
                        <meter id="oemes"><strong id="oemes"></strong></meter>
                        
                        
                        <mark id="oemes"></mark>

                        <input id="oemes"></input>
                        <menu id="oemes"><u id="oemes"></u></menu>
                      1. 网投网官网

                        利盈的彩的网址首页

                        千亿|体育老虎机

                        比分深球足球

                        同乐城 同乐城官网

                        mc彩票网站登陆

                        大发888娱乐场下载com

                        m5体彩登录

                        百利网址