Pivot points represent a market segmentation approach used by many companies to determine market demand, define new products, assign sales territories, service customers, and put boundaries around customer sets. Since September 2009, over 500 enterprise software decision makers were asked which one pivot point would they prefer their software vendor focus on. The four key pivot points include market segment, geography, industry, and role. To elaborate:
- Market segment – standard definitions of size whether it be by revenue (e.g. $0-249M, $250-499M, $500-999M, $1,000-4,999M, $5,000-9,999M, $10,000-19,999M, >$20,000M) or by employee count (e.g. 0-49, 50-99, 100-249, 250-499, 500-999, 1000-2499, 2500-4999, 5000-9999, 10,000-19,999, 20,000-49,999, >50,000).
- Geography – physical and cultural location of where primarily business is conducted (e.g. North America, South America, Latin America, Western Europe, Eastern Europe, CIS, Middle East, North Africa, Africa, India, Greater China, APAC, Oceania, ANZA, etc.)
- Industry – industry expertise or vertically related business functions often generated by SIC code or broad categories (e.g. Discrete Manufacturing, Process Manufacturing, Retail/Wholesale Distribution, Services, Public Sector, Healthcare/Life Sciences)
- Role – classification by job functions and titles (e.g. CEO, COO, CFO, CMO, VP of HR, VP of Security, Architect, Chief Legal Officer, etc.)
Respondents were forced to choose the one pivot point they felt would be most relevant to their needs. The results are as follows:
(Survey of 527 enterprise and sme/smb software decision makers from phone, tweets, email, and in-person interactions from September 2008 to June 2009
The bottom line – end users should demand vertical expertise
The message resonates loud and clear – users seek more vertical expertise from vendors. Making minor extensions to support an industry may not be enough in today’s market. As industry requirements increase and require software solutions to provide support, end users must demand greater levels of innovation and investment into vertical specific requirements. Given how much money has been spent on maintenance and support, end users should take an active role in building the right level of dialogue with vendors:
- Request to join customer advisory boards. Often customer advisory board members have insight into the product direction and future functionality decisions. Some vendors such as SAP, Oracle, Lawson, and Microsoft hold regular advisory board meetings with end users, senior management, product teams, and analysts to define, prioritize, and test requirements. These meetings often result in a status report on priortiziation and progress in delivering the requested functionality.
- Influence existing user groups. User groups may already provide industry specific forums where the vendor and the end users have existing channels of dialogue. Determine how quickly it has taken a vendor to deliver on promised functionality. If it’s been more than 12 months and its a common request among 80% of the users, then it’s time to rally the end users for some change/
- Rally around industry trade groups. Take the time to see what standards have been set by industry trade groups. As vendors modernize their software architectures to support web services and SOA, trade groups could provide a key opportunity and forum to define common business process, architecture, and meta data standards.
The bottom line – vendors should keep focusing on verticals and micro-verticals
By a 3 to 1 margin, software decision makers resonate most with verticals. This continues a trend where customers seek deeper functionality by verticals and micro-verticals in their solutions. Vendors should take the following 5 actions to improve vertical relevance:
- Focus on a select number of verticals based on vendor size. Most software vendors under $500M have the bandwidth to focus on 3 to 5 verticals while those between $500M and $1B can handle 7 to 9 verticals. Agree on what you will not be focused on and treat other sales as opportunistic.
- Build a road map of capabilities that should be part of the vertical solution. Identify the complete functionality of business processes that should be supported. Include both internally built and externally provided solutions.
- Identify solution centric ecosystem ownership. Given the myriad of combinations and customer requirements to deliver the last-mile solutions, not one single software vendor can deliver all aspects of a solution. Determine what part of the value chain will be delivered, externally sourced, or provided by a partner. Keep in mind some customers may choose to extend on your platform as well.
- Enable easy access and extension of the core platform. Design the solution with partnership and extension in mind. Ecosystems provide the fastest way to build adoption of your software. As users and partners add IP and innovation to the core product, vendors gain natural barriers of entry and exit in a specific vertical and micro-vertical. Customers may also seek to band together to build solutions or have a partner extend and industry solution for them.
- Tie the pivot points together. One final point – don’t make the mistake of just focusing on a vertical or one pivot point. Take the time to cross segment by the other pivot points. Vendors often find that these verticals may not fit as neatly across the board and that’s okay. Some solutions such as risk and compliance may have inherent appeal across a role such as a CFO and span verticals. Keep in mind pivot points provide a guide but use common sense when building natural segments.
Related research of interest
May 7th, 2007 “Solutions-Centric Ecosystems Disrupt The Enterprise Software World Order”
August 22, 2007 “Avoiding Failure In Technology Partnerships”
September 3, 2008 “How To Select A Software Partner Solution Offering“
Your POV.
Got a similar view on pivot points? Disagree on this assessment? As an end user which pivot point matters most to you and has your vendor delivered? As a vendor, have you started to focus more on industry verticals? Identify yourself as a vendor, end user, media professional, etc. To learn more about how to build your solution centric ecosystem, design a partner program, or extend your industry vertical strategy, feel free to reach out. Post here or send me a private email to rwang0 at gmail dot com.
Copyright © 2009 R Wang. All rights reserved.
7 Comments »
[...] A Software Insider’s Point of View » Monday’s Musings: Industry Vertical Pivot Points Still Mat… [...]
Vertical software specialists have become the alternative to ERP consolidation. It has been a touch over ten years since the ERP tsunami. Back then, vertical specialization often inhibited growth. Now, consolidation has exposed the vertical achilles heal of the ERP vendors.
My views may be somewhat affected because my company focuses on a single vertical market – to be fair – a sub-vertical. Statistics from this market suggests that vertical specialists can implement faster, adapt to customer needs better and provide a lower TCO.
The approach suggested in this posting does not entirely reflect the current state-of-the-art in software development, sales and implementations. There have been a number of recent changes that makes it viable for software companies to viably and profitably compete globally in a single vertical market.
1. Law of Diminishing Returns Changing
There has been a significant cost for vertical vendors to increase market share within a single vertical. This includes marketing and channel costs where extending to additional countries has a high cost relative to the value. The use of SaaS delivery, Web 2.0 marketing, and development of customer networks enables companies to reach out beyond expensive supply chains.
2. Platform Sunk Costs
Software vendors have typically has similar costs to manage underlying architectures. Vendors have been able to leverage their platforms for additional vertical markets at an incremental cost. If the cost structure for supporting transactional technology for a vertical vendor is X, the cost for supporting 10 verticals might be 2X to 4X. The big change has been the availability of robust open source platform components like Hibernate. Of course, there are transactional platforms available from leading web companies like Amazon and E-Bay. Vertical vendors are now able to less expensively develop using these platforms. Many established ERP vendors are burdened with supporting client/server platforms (ABAP, PL/SQL) and technology acquired through consolidation. So, there does not appear to be a platform cost advantage for the larger vendors. (And, these new options are often more cloud friendly).
3. Myth of Portfolio Management
Larger vendors have advocated the notion of portfolio management where it is better to use software from a single company rather than a selection of best-of-breed applications. (Horizontal or Vertical). The view is that support costs will be reduced so the ROI is better with portfolio management. Organizations have discovered that the technical complexity of ERP software is daunting. XML, Web Services and SOA is making it easier to integrate best-of-breed apps. In particular, computing architectures designed for broad markets tend to have far larger footprints: more computing power, middleware, bandwidth issues.
4. Functional to Goal-Based Interfaces
One of the reasons that Web 2.0 applications have become so successful for the consumer market is that interfaces have focused on user goals. Enterprise software is often functionally designed where users navigate software by function rather than by goal. Vertical software lends itself to understanding user goals so that interfaces resemble the better travel sites where the goal is clear (buy ticket) and process is clearly described. User goals can change among verticals making it difficult to achieve usability.
5. Transition of the Standard Software Model
Software vendors tend to be organized similarly: product management, R+D, support, professional services etc. The VAR/SI channel typically implements these solutions and there are often 3rd party post-sales support. This model has created insulation from vendor to end-customer. So, many vendors become unaware of how to increase success rates within specific verticals. Vertical vendors are leveraging this customer information to fundamentally change their business models. For example, vertical vendors are leveraging deep industry knowledge to help build customer functional capacity. (ERP vendors often promote “best practices”, but these practices are often poor practices in many verticals.)
Doug,
Thanks for your extensive comments. A question to other readers of the blog and you as well – what’s the best way a vertical or micro vertical vendor should plug into the software ecosystems?
R
Ray,
The first step in plugging into any software ecosystem is to determine what software stacks seem to dominate the vertical or sub-vertical. For example, the IBM stack has been the most prevalent in mid to large size group insurance companies. I suspect that the Microsoft stack is more at work among independent fashion retailers.
It is more likely that vertical vendors should focus on either Java or .Net. (The days of 4GLs are over.) If Java is the choice, it is best to develop with a minimum of platform specific code. Nevertheless, one should pick a Java flavor at first.
The software ecosystems provide different entry points:
1. Microsoft
Dancing with the elephant can be dangerous. The vertical vendor would be wise to consider whether Microsoft has selected their vertical or not. The advantage for a vertical vendor of financial, HR, SCM or CRM software is that you can build components on Dynamics products and leverage the generic functionality. This reduces your cost, but can also reduce your value proposition. Microsoft has a good channel that you can tap into. There is a cost of business to become a Microsoft partner and tap into their ecosystem. In general, one can start with a limited investment that gets a lot of .Net development tools at a low price. In my experience, in the past, local Microsoft offices are always interested in what specialists are doing. Vendors need to market actively in the Microsoft ecosystem – attending partner conferences, seminars with local offices, being part of a partner booth at trade shows etc.
2. Open Source
Regardless of whether the products will be open source or not, vertical vendors can tap into open source projects. There are many proven middleware components that can be assembled to form a platform that could be designed for a vertical. There really is no such thing as a perfect software architecture because all decisions made, such as performance vs. fault tolerance, are compromises. The vertical nature of a business enables making the right calls.
Tapping into this ecosystem is easy- through Sourceforge. This option is not nirvana because there is always integration work needed. Many vertical vendors are finding that outsourcing firms in India and Eastern Europe have a lot of expertise in this. Many vertical vendors are very functionally literate within their domain, but often do not have the technical expertise. This is a good option.
There is also the possibility of extending open source business software applications in the ERP and CRM space, but this requires a lot of thought before proceeding. Vertical vendors using open source should become active in these projects should become active.
Many open source components have costs associated with support – especially BI and content management projects. These costs are generally reasonable.
3. Commercial Java Stack
BEA (now Oracle) and IBM provide excellent stacks. Vertical vendors are often suspicious of both. The larger vertical vendor can tap into IBM’s ecosystem and get IBM’s attention – including promoting products. The larger vendor may not wish to do the same with Oracle but introducing the value of an under-served and lucrative vertical. There are numerous partner agreements available, and my experience is that both companies provide good technical support. In my experience, IBM offers better sales/partner support. Of course, IBM will try to convince you to use DB2. It’s best to latch onto any vertical specialists within or adjacent to your market with IBM. They will help you navigate the organization to get the best support.
To add some additional comments:
1. New Ecosystems
The middleware universe has not unfolded exactly as expected. The technology from IBM, Oracle, SAP and Microsoft has matured and attracted an ecosystem of ISVs. There seems to be a disruption, as there often is in our industry. The available of cloud services and the maturing of the Google and Salesforce stacks have introduced attractive alternatives for vertical ISVs.
These more recent players may be more likely to adopt broad industry standards in order to attract an ecosystem than traditional players. Mind you, that could all change as Google moves down the stack to the OS. The key message for the vertical software company is to consider open standards as protection and risk mitigation.
2. Manageability of Supply Chain
The supply chain has become more complex, but manageable via Web 2.0 tools: end customers can now participate in product design and application stores.
3. Commoditization of the Stack
The traditional approach has been to “own” customers through extending the middleware reach. (It is somewhat reminiscent of workstation vendors who tied customers via unique Unix features – that didn’t work out all that well in the end.) The truth is that the stack is approaching free. Open source is well established. Many companies (IBM-Eclipse, Oracle-MyFaces, Tomcat etc.) are providing once-commercial software as open source. Commercial solutions are dropping in price or being bundled to provide more for less. (For all criticisms of Microsoft, they do provide price advantages.)
This means that the value to the customer is at the top: the end application or final mile. Vertical ISVs need to recognize that they should not get into the middleware business.
[...] product road map will provide direction into the future opportunities such as vertical and other pivot points that have not been well served. SAP’s acquisition of Clear Standards for carbon compliance, [...]
[...] Paas, DaaS, and IaaS by investing in white spaces in the solution road map with verticals and other pivot points that have not been well served. In addition, expect forms of SaaS BPO to emerge as clients seek [...]
Leave a comment