orchid connect is up and operational

test

Life-cycle Support – On-boarding

Once someone has decided to buy your service or give your solution a try you’ve got to step into the support system boldly and strongly with four critical paths:

Messaging, interaction, low barriers to entry, and in-depth knowledge of the user.

The process of how people buy and why they buy a solution has been radically transformed. Automatic messages and communications that once felt impersonal are now so personalized one could mistake them for friendly, warm interactions. While these highly-designed, friendly, personal, branded messages and interactions aren’t to the level of being expected, they are becoming the norm quickly.

Smooth interactions – no one wants to have a hard time reaching out, no one wants to feel like they’ve interrupted or that they are being referred to somewhere or someone else. Keep interactions smooth, comfortable and warm. Make sure people can reach out to the right people and keep their communication with that same support professional. When in doubt over communicate and keep it human. Avoid canned, robotic interactions – they don’t serve you.

Low barriers to entry – if using your platform requires a lot of set up and learning – make it as easy as possible, offer add-on service or free guidance. Do everything to hold hands. The uber-user, the early adopters, might cut their teeth on your service without that but everyone else will indulge in differing levels of handholding – make sure you’ve run your numbers and cast your assumptions such that you can afford to fully and completely support the user to the degree that is needed.

Broad knowledge of the user – you should know your users. You should know what they are thinking and the approach they are likely to take. You should use that knowledge to build wizards and popups that streamline the most common actions. Let the user tell you what they are about and then make use of that information in supporting other users like them.

Life-cycle Support – First Contact

The first contact with a user is the beginning of the lifecycle. I encourage you to think of sales and marketing as support. You are, after all, supporting someone’s decision to buy but you are helping their search for answers and solutions. Buying your solution isn’t good for anyone if it’s not the right solution for them.

Thinking about the lifecycle of a user as starting before you actually, land them as a client or take their money should put you in the mindset that over delivers and supports with the user’s needs in mind. It should also get you thinking about their problem and pain and not about how your solution can solve. By integrating the prospective user with the actual client/customer user, you can more completely support the later. The potential user has a great deal to teach you – about their pain independent of your offering. It makes you user-centric, it makes it possible for you to think of the user before you think of what you’re selling them.

Predicting market reception; Launching new products

It can’t be done – predicting, that is. You need data and real-life conversations and truly, time and experience and risk and all the rest. You can guess, and fantasize of course – but anything remotely reliable just isn’t. No matter how many spreadsheets and models and research you do … ask yourself how much you are willing to risk/invest in finding out. To put your product out there and get actual numbers and feedback. How willing are you to take the answers the market gives you – including “nope”? It’s got to be an amount you are willing and able to actually, literally – lose.

Go through the hard work of making peace with the potential of that loss. If its friends and family money – make sure they understand that and that you are willing to understand it too. No matter how confident you are that your idea will succeed – understanding and emotionally embracing even, this concept will help you be dispassionate about the outcome and the potential turns in the road that you will need to navigate.

Nothing is sacred in entrepreneurship – really. Nothing.

Engagement: Clarifying an association’s focus

Every association I’ve worked with over the last 23 years has had a straightforward business model – engage members, prove your worth. Every one of them boils down to member engagement – engage members, and they’ll keep paying their membership fees. Show value in the trade or market segment and members will continue to renew. Host valuable events and conferences and members will come and continue to renew. May valuable inroads in policy and communicate that to members and members will continue to renew. Engage money, and market players interested in the same market will want to reach your members enough to buy advertising, attend events, and sponsor activities. Essentially “be a value, communicate that value, rinse and repeat.” I don’t say this to be glib but simplify simplify simplify. Your questions should be – how to engage and are we engaging? It should be – is this engaging? Every move you make … should center around these questions.

What I see though is small offices constantly being distracted by outdated technology, vague or confusing mandates and wrestling with clear communications and unclear strategic objectives. They don’t have a strategy. They don’t utilize their data. They don’t focus and refocus their mission and vision to align with their daily activities.

Whenever I engage a new association or non-profit I have this overwhelming urge to get a 30,000-foot view of the whole org, dig deep into all the dysfunctions and move earth and sky to get their strategy updated and aligned. This work isn’t easy, and I never envy the lives of my clients – but sometimes having someone come in and help you re-organize your life, your garage, the junk drawers of your organization – give you the freedom and oxygen you need to think and act clearly.

In-App Support: A software’s responsibility

If you’re lucky enough to have gotten people into your application do everything you can to support them there. Do not make them go looking for support if you can answer questions there and then.

Define tools

Sprinkling little “info” buttons around the application is a great way to give people snippets of “what’s this” as well as to send a signal that you want to support their understanding and use. Never miss an opportunity to project that understanding – nor the need to keep this sort of thing up to date. If you make people puzzle things out or go elsewhere to find support around essential interface features – you might as well show them the door.

Access to help

Giving users access to help articles and tips within the application is important. It is no longer enough to ask people to go search for answers or opening an enormous user guide they have to navigate. Taking users out of the software is a mistake a lot of technology companies make. Users have questions that relate to their needs and their use of the application – they care little about the technology or the whys and wherefores of your application. They care even less about your business model and where you draw the line around what is in your job description and what is not. In other words – go out of your way. It pays off.

Conversations

Some of the most effective support layers I’ve seen is those that have integrated their helpdesk conversations in the apps. Most take it out to email or onto the desktop. Creating a layer of communication in the app with a support rep – as well as making that thread/conversation easy and intuitive to find is genius and well worth the effort.

When creating support mechanisms understand that you want people in your app – you want to make it easy. Put support at their fingertips and stay there. If they are accessing your support from the app then they are using the app – don’t encourage them to leave you.

Dos and Don’ts of Data-Driven Strategy

Do use baseline numbers to see movement on strategic goals

Establish a baseline – what are your numbers today? Likes? Clicks? Visits? Members? Donors? The numbers. You cannot change what cannot be measured so come up with concrete numbers. If they start at ZERO, that’s fine too. Choose a few, so you don’t fall into the trap of tracking just one indicator and getting frustrated as a result.

Don’t try to show everything

Detail is of limited use. It isn’t completely useless though so choose what you show wisely and make sure you understand why you are showing what you are showing. Showing it just because you have it – is not a good reason. Come up with a rationale and if you can’t, leave it behind.

Do have clear goals for what people are supposed to take away

Think through the impact of every piece of data you want to share. What are you achieving by showing that particular piece of data? Be concrete, precise and keep it simple. Individual pieces of data aren’t intended to tell the whole story they are “at-a-glance” communication to support your strategic goals.

Don’t restrict everything so as to render them opaque

Data visualization that doesn’t move is just pictures. The purpose of this exercise should be to make select pieces of your data accessible to your users – still, pictures don’t do that.

Do add text explaining the tools/visualization

You don’t have to spell everything out but giving people a context in the form of text will help them understand the importance of what you are showing. Even dashboards can benefit from explanation and guidance.

Web Development Checklist

Existing brand elements – logos, color palettes, style guides

These elements are critical and must be firm. If you’ve never had a designer develop these for you then now is a good time to firm this up. These elements are part of your identity – the path to how people identify you and associate you with your mission. They are not optional, and they should not be squishy.

Purpose/vision for redesign or redevelopment

Be concrete and honest here – “be less embarrassed” is a legitimate goal (if not a low bar) dig into the deeper objectives – if people were happily going to your site – what would they do there? How would it change your organization? Would you sleep better? Why? Get even the unreasonable expectations out on the table – “it would change our world,” “the whole world would know what we do and love us for it” – then boil it down to the concrete, measurable objectives.

[  ] Three central goals
[  ] Three tertiary goals

Strategic goals to be achieved and concrete ways to measure that achievement
Once you’ve gotten honest with your objectives, figure out how to measure them. Hits, visitors, unique views are one element, but they shouldn’t be the only element. You should have an array of measurable outcomes – hits, and visits but also sign-ups and registration, comments and emails … if you charted the path of a user’s engagement – what do they do as they become more engaged? What are the actions they take? It might be useful to develop a few personas (mock user members) who might represent a typical user. As they click, visit, share, register, contribute, complain, renew what does it look like when there are many more of users just like that one?

Architecture including new and old content

No one loves their website but hates their content – or hates their website but loves their content. Usually, an organization has taken so long to address how their site has become outdated that they’ve not spent time on the content. Since they don’t want anyone going to the site, they don’t invest in the content. Eventually, they arrive at a place where they are likely to say “there is very little we’re planning to save of the current site” – still there’s usually stuff. If nothing else there are links. You’ll want to maintain links that are in search engines to protect your natural SEO, but you also want to be clear about what kind of redirects, content migration needs, and who is doing what. Pay particular attention to select things like recurring donations, specialized content management, 3rd party systems and other integrations you may well be taking for granted.

Content ownership and leadership

At the beginning of the process try to be clear-eyed about the ultimate ownership of content. Many organizations have aspirational goals of “everyone contributing” to the website. After 20+ years I’ve concluded this is unrealistic, though admirable. What typically happens is everyone dumps their content onto one or two people in the organization. This doesn’t mean the goal of having a site “easy enough for anyone with some training” to manage is a bad thing. It’s the correct goal. It is also essential that the effort to update and publish be low enough that the dumpees do not have to re-learn or develop specialized skills to operate what should be a core function of their duties.

Editorial calendar

“The site needs a makeover – the content is atrocious. We’ll rewrite some of it, but most of it isn’t even coming over. The rest we’ll do once it’s launched.” Sound familiar? I’m not sure I can remember the last project we did that DIDN’T have this sentiment. I advocate coming up with an editorial calendar – based on the skills, priorities, and objectives of the organization. It needn’t be written in stone, but it needs to be real. Getting concrete topics set up and expectations clear will help keep things from grinding to a halt. The effort of redesigning, and redeveloping a website is a big one – preserving the momentum is essential.

Required functions and their relationship to the strategic goals and objectives.

Get practical. What functions do you need on your website? Be explicit and concrete – newsletter signup, foldout navigation, blog topics, search – these might be obvious but between you and me – a developer might not agree about the definition of “obvious.” Be sure to crawl your site for little-specialized tools and features like quizzes, calculators, forms, widgets. All of this impacts the implementation, and all of it is “devil in the details” stuff. Often this kind of thing is buried deep in the site – it may or may not need to move, but someone needs to decide.

The orchestra conductor is essential: why skilled people can’t work together without leadership

Software isn’t unlike a piece of classical music – each part doesn’t wholly make sense without the others – to the whole is much more than the sum of the parts. Certainly, the interface without the code is pretty to look at but not functional. The quality is not divorced from the function. The purpose is not removed from the market itself or the problem it attempts to address. All those moving parts need leadership in much the same way as an orchestra does. When each part of the team needs direction, and when it only plays a supporting role. A good technical leader is seeing the path forward and identifying roadblocks and congestion points. A good leader can troubleshoot and find solutions quickly and confidently. A good technical leader can guide your team, save you money and protect your interests.

Sales Support is Square One

I hear it over and over again – “my sales staff isn’t making their numbers.” It is said as if they are on an island by themselves and failing no less. Salespeople are expected to have a gift and perform the mysterious task of selling the product. There’s nothing magical about sales – save for where the passion for doing it comes from. It is a task that most people would rather chew their arms off than do. Sales are all method and strategy – two things that need support – rigorous, focused, evolving support. If you support your salespeople with good materials, expectations, and alignment – then the feedback salespeople bring back to you can be as useful as any. It is simple – If you don’t support your salespeople – they can’t do their jobs. When someone tells me they have the “wrong salespeople” I ask them what they’ve done to understand what’s missing.

Technical leadership: 3 reasons paying for a lead is important

A strong leader understands how all the parts fit together and has a dynamic understanding of how things move through the team, whose strengths are where and where another team member needs scaffolding. This strength can save you time and money. Anyone can hire someone to do as you tell them – take the time to hire a leader who can tell you what’s best.

1) Experience failing

A good technical leader is going to have lots of experience failing. It is the nature of technology and leading technical teams. These failures need to be the biggest teacher because they have the greatest value. An experienced technical leader should have a process through which they review (post-mortem) the project and identify the gaps and concerns that caused problems, delays, and issues. Without such a process the experience still exists, but it is hard to put it to work with a team. The team should be able to access and make use of this experience too.

2) Familiarity with common approaches

You want a technical leader who can listen to a developer’s approach to a problem or task and ask intelligent questions. They need not necessarily be a developer themselves, but they should have had enough time in the saddle to know when a developer is going off on a tangent that’s not necessary. They need to be able to smell BS. It isn’t that developers want to waste time, but the focus and logic that makes developers valuable can also be the trait that keeps them from being focused on the bigger picture.

3) The ability to translate

It’s often said that developers are from mars and then there are the rest of us. Ok, maybe that’s not often said, but we’ve all thought as much. A good product or technical lead will be able to translate market, sales and user need to technical people without frustrating either. This should also lead to the ability to anticipate questions from any interested party, the ability to break down vague helpdesk requests and get to the heart of issues.

An experienced, focused product lead is worth their weight in gold.

1