Try.Hyland.com
Part I

Background

​

"What will be your legacy at Hyland? You know, that thing that everybody will eventually come to know you for. And I don't mean what your role was or will be, but rather, will the things you've done still be relevant 10 years from now?" 

​

Those were the types of questions my manager would ask that provoked some interesting conversations. At the time, our team was known as Demonstration Services, a wing of the Technical Sales team that was responsible for providing the tools, training, and resources for sales engineers. My main responsibility involved managing a virtual machine that sellers could use as a starting point for building custom demos. It came with just about everything that a seller would need to show a live demo, and as the owner, I was responsible for upgrading the software, enhancing the base demo content, and configuring new demos to leverage new software enhancements. It wasn't the dream job I had in mind, but it came with a lot of autonomy and I felt like I was making an impact. It also provided a lot of exposure to various enterprise software (we had several at this point) and opportunities to work with a wide array of teams. 

​

Not too long after my manager had asked me that question, there was an announcement that he'd been asked to start a new team in a new role. His current position would soon become available and interviews were to shortly follow for interested candidates. At this point, I'd only been on the team for just over a year. However, I'd been at Hyland for several years now holding various roles, and my prior background seemed to make me a natural replacement for the position. I happened to also be the only person on the team to apply, so I felt fairly confident about my opportunity. 

​

In short, I interviewed and was not selected.

 

As it would turn out, a former colleague had also applied and was chosen. He was (and still very much is) a friend and somebody that I respected. He also happened to be my former team lead. While it was disappointing to not get the position, he was the better fit and I wasn't as prepared as I thought I was for all of the ensuing challenges that would come with the role. 

​

If not managing the team though, then what was next? I didn't mind managing our demo platform, but I'd been doing it for a couple years at this point and was starting to look for that "next thing." I brought this up with my new manager during a one-on-one and we began brainstorming. One idea that came up centered around a small website that the team had "inherited" several years prior. The site was called Try.OnBase.com and it was intended to give customers and prospects an introductory experience to Hyland's flagship product, OnBase. Try.OnBase was developed by a former team member as a side project, but that member had left the organization and there wasn't anybody on the team intimately familiar with the site. Without an owner, technical challenges began to accumulate. The first and most immediate came when the company's app security team had concerns around a major piece of the site, the demo labs. It was determined that they needed to be removed, and as a result, traffic on the site took an immediate tumble. Users were vocal about their desire for the labs, but with nobody working on the site, a replacement solution wasn't on the team's roadmap.

​

Aside from the technical hurdles, Try.OnBase.com was also struggling with content. The site was originally built to provide customers and prospects with hands-on access to OnBase. However, changing buyer expectations resulted in users wanting access to all of the product’s functionality as well as the ability to do more product research on their own. Additionally, Hyland had acquired several products that complement the OnBase platform but had no place on the site. While customers could solve nearly any business challenge with one of the tools in the Hyland portfolio, there were no hands-on experiences for customers to learn about them.  

​

Try.OnBase certainly had great potential, but it would require an owner if it were to be kept around. Aside from the fact that neither of us had any experience with running a website, we felt confident that we could turn Try.OnBase into a meaningful sales asset. We agreed that this would be my next challenge. I would own Try.OnBase.com. 

​

​

Getting Started

​

The thought of "owning" a website with so much potential sounded exciting, but figuring out where to start quickly became a challenge. This wasn't like past projects where there was a defined output that leadership was pushing from the top down. Rather, we were on a path to create something meaningful out of a problematic situation that had the potential to get worse if not addressed. We needed to set a vision, manage our own roadmap, and find the teams and resources to help us make it happen.    

​

We started with the vision, which luckily for us, was somewhat already defined. It'd been preached to us that customers want to do their research before engaging with a vendor, and we’d also heard that customers were struggling to find easy ways to learn about the company’s solutions. In fact, we even had a customer share a story about one of their business units procuring another software platform because they weren't aware Hyland had a solution. It would be these few things that we’d base our vision off of. We would become a one-stop resource for users to learn about a Hyland offering, understand the business challenge/s it solves, and give users live access to try it for themselves. We would also make it easy for users to engage with product experts, find training and documentation, and request to connect with their account team, all on the same page. Anything we could do to remove barriers and expedite the sales process was our new focus.        

​

With a vision in place, it was time to begin laying out the major tasks involved and creating a pitch to start sharing the idea with others. We didn't need anything elaborate, but it needed to be detailed enough to convey our plans and demonstrate that the idea was worthy of dedicating a full-time resource to it. Our outline consisted of the following: 

​

• A New User Interface - The look and feel of the existing site was dated and the branding was also off. In 2017, Hyland acquired a large competitor which included the addition of several products. As a result, all of the company’s websites were now under the Hyland.com domain and the brand guidelines had also been updated. We needed to get the site to the new domain, and we also needed to start matching the styles of the other Hyland site to make it feel like it was a part of the Hyland ecosystem.  

​

• Return of the Labs - The best part of Try.OnBase.com was the labs. Labs came with pre-staged virtual environments and detailed step-by-step demo guides so that even a first-time user with no pre-existing knowledge of the software could follow along. While other experiences on the site allowed users to be hands-on with live software, they weren't as flexible and it limited what we could provide to users. We needed to bring back the labs. 

​

• Content -  The acquisition of Perceptive in 2017 included several products that Hyland would continue to develop and support. Hyland had also started developing an Enterprise File Sync and Share product (similar to Box/Dropbox) and there was now a list of products other than OnBase that customers could take advantage of. We needed to quickly expand the variety of labs available and set the tone that this site was going to be for all Hyland products, not just OnBase.    

​

The last thing we needed before going to pitch was a mockup and a presentation. I used a tool called Balsamiq in a previous project to design and prototype a business app. Using the tool, I was able to create a wireframe for the site and link multiple mockups together to create a pseudo demo. A couple of PowerPoint slides were added and we were ready.

​

​

Selling Internally

​

The first people that we met with were our own technical sales leaders. Both my manager and I were previously sales engineers and had great relationships with these team members. The purpose of the meeting was less about getting approval and more about getting their opinions on what would be most important when pitching our idea to senior leadership. In particular, it was advised to position the project as a way to adapt the company's selling techniques with that of changing buyer behaviors in the industry, something that'd been a theme in recent meetings. The advice paid off. When we met with senior leadership, they could easily connect how our project aligned with their strategy and even identified some additional requirements to incorporate into the final project. These requirements would uncover a handful of additional teams that we'd need to coordinate with, and in hindsight, skipping the meeting with our own technical sales team could've led to many downstream challenges.            

​

​

Selling Externally (i.e. Non-Sales)

​

Preparation

 

We now had our leadership's approval to move forward. Not only did we have their buy-in, but by having it, we'd also be able to leverage this commitment when presenting our initiatives to the teams we'd need assistance from (in particular, Legal and IS). By simply sharing that we had approval up to the SVP level, I truly believe it helped us establish our credibility and gain buy-in from the other teams as well.  

​​

We’d determined it was now necessary to further refine our requirements and start filling in more detail. What would've likely been too much detail for a presentation to Sales leadership would've been the opposite when meeting with the other teams. We wanted these teams to understand the full scope of what we were asking for and also get a better idea of the types of requests we'd be making. Writing detailed requirements would also be a great opportunity for us to start building our backlog and being more intentional about how we were spending our time.    ​

​

We started listing tasks for our three major objectives which ranged from updating the site logo to building new labs. We then determined if each item was critical to launch or whether it was something that could be completed post-go-live. Time estimates were added to each item to help build a timeline, and we now had a rough project outline completed. It didn’t have to be perfect as we knew the list would continually grow and change. What was important however was that we could now show everybody (including ourselves) that a plan was in place and that we could at any point discuss our progress. Lastly, the outline allowed us to generate what we thought could be a reasonable (but still very murky) launch date. 

​​

With our requirements in hand, it was time to start meeting with the teams.  

​

​

IS

​

The first team we met with was IS. They were already hosting the existing Try.OnBase website and the assumption was that they would also be the team assisting with any technical changes required going forward. We also knew they supported numerous applications throughout the company and that it may take some time to get a spot on their project roadmap. While we already had a good inter-departmental relationship, we also recognized that the level of effort for this project was well beyond anything we'd requested in the past. It would be a balance of priority and understanding in terms of where we fit in.   

​

We met with just a small group. The IS manager brought a couple of his senior team members and we walked through the presentation we'd shared with our Sales leaders. We also shared our newly refined requirements which they seemed fairly optimistic about. In hindsight, I think being able to show the requirements written out in detail went a long way. I believe the extra detail not only made it easy to get a solid understanding of what we were envisioning, but I also believe it demonstrated that we were at least somewhat competent for the journey ahead. As optimistic as they were, there was a final twist when the dev team agreed that this project would require a rebuild of the entire site.

​​

Rebuild? From scratch? We already had a website and the plan was to keep the existing content. Huh?  

​

It would be explained that Try.OnBase.com was currently hosted in an environment separate from all of the other Hyland sites. That instance was running an old version of the web platform, and instead of trying to upgrade and migrate the existing site, it would be better to build a new site in the same environment as the other sites. As expected, it was confirmed that this would require more work but would be beneficial in the long run. 

​

Our initial concerns about how this would impact the project timeline were quickly trumped by the numerous benefits that came along with a new site build. For our team, it meant that we could design the site from the ground up without having to worry about constraints from the current system. The developers were also happy to hear that they weren’t bound to any code written in the old site and could instead structure the new site in a way that aligned with their current methodologies. Both of these would result in being able to provide a better experience for our end users (i.e. the people that really mattered) and a better foundation for future development. 

 

It's also worth pointing out the value that this brought to the company as well. By rebuilding the site in the updated platform we were also able to accomplish the following: 

​

• Retire the old servers/licenses required to host the legacy platform

• Reduce the number of environments that require future upgrades

• Reuse existing code written for other Hyland sites 

• Dynamically share content to/from other Hyland sites

​

It was a true win-win-win for all teams.

​

​

Legal

​

With IS on board, it was time to share our project with the legal team. Unlike our IS team, our involvement with Legal was limited. We'd once worked together to get verbiage for a partner EULA (End User License Agreement) and to update our Terms of Service page for Try.OnBase.com, but other than that, our relationship was non-existent. We had a single point of contact with the department and we hoped that they could point us to the right people. Luckily, they were able to. 

​

We scheduled an introductory meeting in the building across the street where the legal department was located. Since we didn't always have a relationship with the people we'd be meeting with, we'd try to find ways to make it easier to work with us, especially when first getting to know each other. Our relationships meant a lot to us (and to the success of the project) and it was important that we got off to a great start. In hindsight, the relationships we built with other teams would be a large contributor to our overall success. 

​​

Tip: Building strong team relationships can be reinforced with basic acts of kindness. I'll claim the day we won over our development team was when we simply asked if they'd allow us to take them out for pizza. They picked the place and we picked up the tab (~$40). The pizza was irrelevant. It was about getting to know the people we'd be working with, and from that day forward, it felt like everybody was extra candid with each other. 

​​

Back to the story. 

​

We quickly found that how requirements were handled with Legal would be very different than how they were with IS. With IS, we had general ideas of what we wanted and knew we could always tweak the details along the way (as long as it didn't require legal approval). With our legal team, however, every use case was required to be explicitly defined up front, and in some cases, approval was needed for one requirement before moving to the next. Any deviation from the original requirement meant going back through the approval process, there was no tweaking. It may sound painful, but there were good reasons behind it. The project was started towards the end of 2018 when data regulations/privacy were (and still very much are) a major topic. Things like GDPR (the EU's General Data Protection Regulation) had just gone into effect, and it wasn't uncommon to see a well-known company in the news for a data breach. The penalty for making a mistake at this level was severe (large fines, damaged reputation, etc.), and any major violation would likely mean an end to the project (and potentially for the person running it too).  

​

​We also found that there were a handful of occasions where Legal would require additional time for research. Some of the use cases we’d provided were simply things they'd never seen before and combined with the constantly evolving laws, some scenarios quickly became more convoluted than anticipated. We would eventually get approval for all of our use cases necessary to launch and all teams felt comfortable moving forward.  

​

​Tip: I learned many things in the Try.Hyland project, but learning how to effectively incorporate a legal team member into a large project is one of the most critical. Below is a checklist of the most important details:​

​​

• Include a legal team member early and often. Their involvement should be looked at as an ongoing relationship, not a checklist item.

• Be clear, detailed, and honest about your requests. Additional details provided after the original request can, and likely will, require additional time.   

• If you're unsure, ask. Don’t make assumptions.

• Do not become a middleman. If your leaders require something that doesn’t get approved, get them directly involved if necessary. Likewise, if you’re working on a technical project, ask a technical team member to respond to legal inquiries instead of trying to provide them yourself. 

• Be considerate. Your project is most likely not the only one your legal team is working on and immediate responses may not always be possible.

• End-of-year (fiscal and calendar) is a very busy time for legal teams. If your request can wait until after the new year, propose that the request be addressed after things have settled down. Just don't forget to follow up if you haven't heard back within a week or two after that period.    

• Remember that your legal team's top priority is to protect you and the company. If they reject one of your requests, it's most likely for this reason. They do however want you to be successful and help you accomplish your objectives in a legally compliant manner. 

• Do not wait until the last minute to include legal. You'll be very disappointed to learn that something you're ready to launch cannot go live due to a compliance issue (I've witnessed this in a colleague's project and it's not fun).   

​

​

Getting to Work

​

As we were meeting with the supporting teams, we were also actively working on items on our task list. The two things that needed the most immediate attention and would take the most effort were the lab replacement and the new UI. We knew that both would almost act as mini projects in themselves and so we treated them that way and created milestones and subtasks for each. ​

​

​

Lab Replacement​

​

There was little doubt that we had to bring back the labs if we wanted people to use Try.Hyland. How we would do it however was the bigger question. We had concerns about building something in-house and we didn't have a pre-approved budget allocated to the project. Getting funds to procure a lab solution wasn't out of the question, but it would need to be a cost-friendly option. We got lucky, and the solution was practically right in front of us.  
​

As previously mentioned, our IS team supported a range of applications and websites. One of the other sites they assisted was our online training platform owned by our Education Services team. While discussing the topic with one of our developers, he suggested reaching out to them as they'd just contracted with a lab platform vendor for training customers. Interesting. 

​​

Before reaching out to the team, we went to the training website and launched a few labs to test the experience. It was great. The labs were filled with more technical content than we'd put in a sales website, but we saw the potential. Most importantly it was clean, easy to use, and aligned with what we were envisioning.

 

We met with the Ed Services team who acknowledged they were still learning the full potential of the platform. They really liked the capabilities, and just as equally, the vendor. It was a smaller company, but easy to work with and the account manager was described as one of the nicest people you could meet. Best of all, they shared their contract pricing and it was well within what we thought we could get approved. We moved quickly with our procurement team to set up our first call with the account manager.  

​

It's not always the case that things turn out to be the way they’re described. However, this would not be one of those situations. The account manager was very welcoming and easy to work with from the start. It wasn’t far into our first call that she was already eager to help. The platform was marketed towards training end users and performance-based testing, so when we told her we were going to use it as an enablement and selling tool, she seemed intrigued. We gave her a quick demo of Try.OnBase.com and explained what we were trying to accomplish. Although she'd mentioned none of their other customers were using their software in this way, she agreed that we could have a trial key and start working through our proof-of-concept. As long as we were working in good faith, we could continue using the key free of charge until we were ready to sign a contract. 

​​

The lab challenge had been solved and everybody could feel the project picking up steam.

​

​

A New Image

 

When we decided we needed to change the name from Try.OnBase.com to Try.Hyland.com, we knew we wanted more than a name change. Not much had been updated since its original release and this was our best opportunity to overhaul the site. It was a fresh start.       

​

I'll preface this by pointing out that I'm not a designer by nature. Over the course of a few years, I'd spent some time building business applications and dashboards, but by no means was designing an interface my strongest skill, nor was this the time to try to change all of that. We needed professionals, and luckily we had some on the IS team. Using the original wireframes, the team incorporated some of our ideas into a few designs that we could pick from. They also made it clear that the final choice was up to us and that we could choose to use one of their designs as-is, use a modified version, or go with something of our own.
 

I always appreciated the fact that we were never locked into a particular solution designed by the IS team and that they gave us full autonomy (within reason) over the site. I also truly believe that their team genuinely appreciated the fact that we took their advice and trusted their experience when making certain decisions. While both teams had different roles and strengths, we both had the same goal of making a site that customers loved and were able to make a better product because of it. 

 

After a few hours of reviewing the designs with a couple of other teams, we made a decision and moved forward. I highly value the approach of making quick decisions and iterating instead of trying to design the perfect solution expecting and expecting it to never change. From the start, we knew that the site would continually evolve and getting caught up on minor details wouldn't be a good use of time (especially since there were only two of us). If we didn't like something we could always change it, but we couldn't get our time back. We also knew that we could spend any amount of time debating a decision and still make the wrong choice. Strangely, I now find myself applying the same approach to decision-making in my personal life.

​

​

Build 

​

We were now at a point where most of the major hurdles had been resolved and the developers were starting to work on the website. For the past few weeks, I'd been learning the new lab platform and building what would be the first set of labs that launched with the site. While the site rebuild was important, it was equally important that people saw value in the content. Without great content, we risked getting users to the site only to see them never return. And to be great content, it has to be relevant to the user. This meant we needed to start branching into areas outside of OnBase. ​

​

Coming from a services and pre-sales background, I had a strong understanding of OnBase and was capable of writing all of the labs for the product. It was a different story however when it came to our other products. While I had basic exposure to them, the products were complex and it wasn't going to be feasible to try to be an expert at all of them. It was time to start leveraging the skills of another team. 

​​

The Sales Engineers at Hyland owned most of the demos. They were well respected on the sales floor and it was common for each team member to have worked with their respective products for many years. Some of them would even tell you stories like how their product had been acquired and rebranded four times or how they were once one of the original developers. They knew their products and customer's use cases better than anybody else, and it was this team that would be our pathway to supporting the other products on the site. 

​​

Up to this point, nobody had really heard of Try.Hyland.com. We didn’t want users to have a poor experience with a site that was still being built, so we didn’t make an announcement or share its existence until much closer to the launch. The only people who knew about it were those close to the project. However, to convey our objectives to the SE team and request their assistance, we’d need to start opening the site to more users. 

We started with a team that owned one of our other popular products, Brainware. Brainware would be a great starting candidate for the site as it was a popular product to demo, it could be sold to any type of customer, and I even had some fundamental knowledge to provide base-level support when needed. We also had a good relationship with the SE team as an added bonus. After reviewing the website and our objectives, the initial reaction from the SE team wasn't quite what we were hoping for. As it would turn out, the SE team presented several concerns including, but not limited to, the following: 

​

• Brainware is a complex product and not something that should be positioned without specific customer requirements

• “Does the performance of the lab environment support the software or is it possible it will lead to a bad experience for the customer?” 

• “How will the customer see THEIR documents being processed?” 

• “How many customers are we expecting to use this?”

• “This looks like a lot of work…”  

• “Are we the first team to do this?...” 

​

The SE team brought up a lot of legitimate concerns, some of which we didn't have a great answer to at that moment. However, we knew that for the site to be successful, we'd have to make more products available. If we couldn't get this team on board, what would be the chances of getting the other ones to commit either? 

​

We wouldn't be sure about things like the lab performance until we tested it, and it was also difficult to predict how many users would leverage the lab. However, both teams agreed that the lab could be used as a replacement for the harbor tour demos the team provided, and it could also be used as a training environment for new users. Instead of seeing it as a way to increase sales, it was now being viewed as a way to remove low-value tasks. We offered to support the environment and write the lab guides while they would help us configure the demo and troubleshoot any environmental issues. They were on board. It was happening. 

​

In hindsight, we were very fortunate to have the supportive SE team that we did. Not only did they help us get a second product onto the site, but based on their feedback, we were also able to greatly improve how we pitched Try.Hyland to other teams moving forward. As a bonus, we were able to translate their concerns into site enhancements that improved the user experience for all users (for example, we added lab surveys to validate that people were satisfied with the lab content).

​

​We now had our first site advocates as well as a revamped process for onboarding new products/teams.

​

​

Making the final turn

​

We were close. Over the course of several months, we'd gone from pitching the idea of a website turnaround to giving access to our first users. It was decided to do a soft launch without a major announcement so that we could gradually introduce users and have a chance to fix any major issues before opening it to everybody. To be clear, we felt comfortable with the current state of Try.Hyland, but the site covered a large variety of use cases and there was much more to the site than just the labs that needed to be validated. Even though we’d thoroughly tested internally, we wanted to be sure as a bad first impression would've presented many future challenges. 

​

​It was also at this time that we'd gotten our first experience of a major team shake-up when it was announced that our lead developer would be leaving the company. It sucked. We'd worked with this person extensively and he was responsible for what was probably 80% of the overall development work that went into the site. A new dev lead was assigned with the understanding that it would take time for them to get up to speed. In retrospect, the decision to hold off on making a large release announcement provided a little more time for all teams to get acclimated to the change.  

​

We'd use the next few weeks to work through any kinks in the site and to introduce more users. Our company conference, CommunityLIVE, was only a couple of weeks away and we were on the fence about how to share Try.Hyland. On one hand, the site was now well-tested and it could immediately provide value to customers, partners, and even Hylanders. It also had the benefit of being free, so there wasn't much risk for users to try it. On the other hand, due to a contractual limitation, we could only publish a specified amount of labs until our new contract became active. This meant that even though we had a fair amount of labs created, only so many could be made available at any given time and there were potential concerns about the site being underwhelming. We knew the content would eventually be there, but would our users give us a second chance if they didn’t see anything they liked? 

​​

We ultimately decided to not make a broad announcement until we could include the additional labs (which were only a few weeks away). However, anybody that wanted to share Try.Hyland with their customers or partners was encouraged to do so at their discretion. This quickly changed when shortly into the first day of the conference I received a text message from my manager. A long-time Hylander and senior leader was on the stage sharing Try.Hyland.com during their session. Others were also sharing Try. Hyland in their presentations and the site was live.

​

​

Part II

 

Part II is yet to be written but will cover the post-release and ongoing ownership of the site. This will include but not be limited to the following:

 

• The first 6 months

• Platform expansion (the technical side)

• Platform expansion (the people side) 

• Mistakes made and lessons learned (along with tips for avoiding them)