Skip to content
Karma

Karma: What’s it all about?

I’ve been having a wonderful time thinking about Database Sherpa. I am grateful to have the time to develop a process that will work for all organizations. Maybe a little history would help for those new to my concept.

It started about 20 years ago when I was running my business, Hopper Business Solutions. Hopper was the embodiment of my dream to run my own business, be my own boss, and to change the way women were viewed in technology. In the beginning, Hopper provided Internet consulting to emerging businesses, but over time, turned into much more.

In addition to creating new databases, I started modifying existing databases for small businesses and nonprofits—systems created by another consultant prior to my arrival. Whenever I began a project, I always found a mixture of disgust, frustration and anger with these systems. I never enjoyed walking into a place with such negative emotions. I often heard these complaints:
  • “The consultant never listened to us and did their own thing. I don’t know why we have to capture the client’s (shoe size, favorite color, etc.). So we don’t and leave that field blank.”
  • “The reports don’t give us what we need. We fill in all the information, but the reports are missing a lot of information that is in the database. Our data is trapped.”
  • “The consultant never finished the database because we ran out of money (or worse, they stopped helping us and moved onto another project). Plus, they worked too much on what they felt was important, and not on our immediate needs.”
This litany is probably no surprise to organizations that have probably at least one such pain point with their former or current system. Let me just say this: It’s NOT just the consultant’s fault.
How can I say this? When I began working with unhappy clients, at some point they say that they had forgotten to mention something to consultant, emphasize the deadline, or take control of the project when things got out of hand. Blaming the former consultant was an easy out.
But, these are mistakes that happen. Even to the best consultant. I wondered, what could we do to make these complaints a place in the past? How can we, as consultants, pass on our knowledge and skills so that the client is now capable of doing the work needed? How can the client be put in the driver’s seat and the consultants be the guide? How can we make our clients happier—and more productive—than when we began with them?
My search for these answers lead to the birth of Database Sherpa where we have a simple value: Bring compassion and joy to our clients, all the while helping them achieve good database karma. (Thanks to DVQ Studio for that fun word combo).Yes, I said JOY. Database work can be tedious and boring. Sometimes it’s even downright frustrating. There is enough frustration in the world, and we have a strong desire to change that. So we approach every project with a positive attitude and encourage lots of laughter and fun to bring back the smile! Now, about that database karma thing, I’ll get to that in a sec….
So, what brought about this thinking about going the extra mile to bring joy into work? Well, recently I’ve been in dialogue with another consultant who has also gone down a similar path, albeit for much longer than I. She has lots of great stories and results, and she’s quite a guru who is becoming a dear friend.She feels it’s important to meet the client where they are at the time they contact her. She told me, “I want to work with clients whose missions I feel strongly about, that I want to support. It’s important that I meet the client where they are, not where I am.” She’s quite compassionate to her clients, and I am sure I can learn more from her as time goes on. And I am in complete agreement with her. We could all learn a thing or two about compassion! She makes a compelling case that makes a lot of sense to me.

We should all help those that reach out to us. Give them the guidance and tools they need so that they are more capable and empowered to drive their mission in the right direction.

But, before you run off sharing your wisdom with everyone you cross paths with, I’d like to offer a caveat. While it’s important to help organizations that to seek change, it’s also critical to make sure they align with your core values.

A key core value at Database Sherpa is to help build good database karma for organizations (I said we’d get back to that). What is this database karma and how does it work? Well, it’s not the karma from the eastern philosophies, or from the TV show, “My Name is Earl.” It’s about destiny to a small extent, but karma is more about action than anything. (And as an aside, I’d like to say there is really nothing “good” or “bad” about karma; it just is.)

Taking this concept one step further, we also believe you cannot outsource your karma. You can’t blame your karma on a long-gone consultant. Good database karma is the result of organizations investing energy to create its database and taking ownership of its long-term maintenance and evolution.

In order to bring positive database karma to organizations, it’s crucial that they be open, be willing to spend time and learn, and be capable of making their database work for them. Good database karma is not as simple as importing data from a spreadsheet. It requires being patient, practicing compassion, facing your fears and doing it “self mommy“.

So, my friend will continue to exhibit compassion for her clients, encouraging and guiding them—even after they’ve started working with her. (A workstyle I greatly admire.) Compassion can have a powerful outcome. It could change the world by making us active, rather than passive learners. (If you read my last post about compassion, you’ll see why I’m such an idealist now.) Ultimately, we desire the same outcome: To make our clients successful with their database systems and increase their knowledge.  My friend has already achieved that, achieving great success and admiration from her clients. That is a wonderful feeling and one she is very proud of.

As a Sherpa, I dream of a day when my client will outshine me and go on to do great things in the database community. I bow deeply to my new friend who has given me food for thought and opened my eyes to other possibilities.

Not Everything is Black and White

Challenge the Status Quo… Changing Process

Lately, I’ve been thinking about how the proposal and payment process takes place at Database Sherpa. Currently, I am using this model:

  • Collect requirements from the client
  • Write proposal based on the collected requirements
  • Client accepts proposal
  • Start project
  • Bill at milestones defined in proposal
  • End project
  • Bill last amount

I’m just not satisfied with this current model. Why? It’s not that I’m uncomfortable with figuring out my worth or uncovering the requirements of the client. What bothers me is that the model is about getting it right from the start. Here is what I mean:

  • gathering the requirements at the start
  • getting the hours in the proposal based on the requirements
  • figuring out any contingency up front
  • sending bills out at the correct times, which means that the milestones are pre-scheduled or defined well enough to bill
  • ending the project at a specific time
I have often struggled at finding that fine balance between the proposal and requirements. I venture to say, most of my consultant friends struggle with this as well. This model often brings me great unhappiness and, I imagine, clients frets about it as well. What I see is missing is the room for compassion or fun. The rigid and inflexible focus of the beginning of the process, to me, is the main point of unhappiness. The more I think about this model, the more frustrated I become. So, I am embarking on a journey to see what else can be done. Something new and fun with the compassion at the core.

Being a person who likes to contemplate, I started thinking about the process of requirement changes in the current model. Here is an example, my client has learned something new about their organization. They didn’t realize when we first started collecting the requirements and I neglected to ask. My first step is to discuss the finding with them, document the change and the impact on the original requirements, create a change order that explains the impact and figure out how much time it will take to modify the requirements to meet the change. I would then give said change order to the client with new amounts attached. They would sign the changes and ONLY THEN would we proceed. This just doesn’t feel right…. my brain kept going back to thinking that we should be celebrating the learning and acknowledging it in a fun way. How could we make this less about the document and more about the learning? What would that look like?

So, you see, I would like to turn this model on it’s head, and find a better way to work with our clients. Thus, I have begun researching other ways and the path has lead me to the PWYL (Pay What You Like) or PWYW (Pay What You Want) model. This model allows the customer to pay what they like, including zero, for products that a company provides. This is a very flexible and participatory model which is guided more by the customer.

One big, frightening issue with this model is that I can’t work for zero! That’s just not feasible as I need to put food on the table. But, I do like the theory and what it could do to the current process. So, I’ll wander down this path for a bit and see what comes up.

I am aware that changing the current process at Database Sherpa means that change will occur in myself and my clients. Since a change like this can be difficult and stressful, I realize that I need to research ideas that are being implemented by others first. So here I will share what I have found thus far and will continue to write other blog posts as I experiment and learn.

What I have learned and read so far is that the PWYL model it’s not about what you CAN pay as much as is it about what you would LIKE or WANT to pay. It is about WORTH or VALUE for the service received. A great example, that most of us follow, is tipping a server at a restaurant. We will either tip 15% or 20% for great service or only 5% or 10% for really poor service. Sometimes, we may tip even less. Again, we are paying what we WANT for the VALUE of the service. Not what we CAN pay.

My first connection was through a friend, Emily, who sent me a link to this blog post written by Tara Joyce (TJ). As a result, I began an email dialogue with TJ about her experiments with this PWYL model. She’s been experimenting with this model in her service based business and here is what she shared with me via email:

If you can design, communicate and supply your service/product in those terms (unique, exclusive), it may be a good system for you to use.

What I’ve found using it is that it’s a good system to use if you are confident in:

  1. your self and your business worth
  2. communicating your worth effectively
  3. how clearly you’ve identified how you are of service
  4. how clearly you have identified your ideal client

When I place Database Sherpa against the backdrop she has outlined, I find it’s a great fit. I’m very confident in the business process and the worth to the client and am working with a great firm (see my previous blog post about fear) to communicate that worth effectively. The ideal client is one willing and able to take their time and learn on their own. Self-starters and people who desire something different.

Now, I need to figure out what something new would look like. That means that I needed to do a bit more research. So, I decided to look specifically at how the PWYL model has or has not worked for others and read some academic papers on this topic.

I started with reading some academic papers as I wanted to ground myself in some theory. I started with a paper that TJ referenced in her blog post. This paper gave me two very specific finding related to the consumer (or client, in my case). They:

  1. need an internal reference point for pricing a product.
  2. base the final price on: fairness, satisfaction, market price, awareness and net income.
This paper also does a great job of explaining, in wonderful mathematical detail, how the PWYL model can work and for what types of firms. What I learned is that the model is most profitable for risk neutral companies AND that the company should be unique enough to differentiate itself from the rest of the market.
What I found lacking with this paper is research based on a service based business. The entire paper focused on the consumer purchasing a product. But, if I take broad latitude and replace consumer with client and product with service, this paper provided me some great insights. The main point of an internal reference point for pricing a service gives me pause. Why? Well, most organizations don’t have a reference point for pricing Database Sherpa projects.

The other place that gave me pause relates to net income. Many of our clients are nonprofit organizations that have no net income. How would they be able to base a final price on something they don’t have?

Challenges! I love those. I imagine they can be overcome with thoughtfulness and purpose. So, let’s keep digging!

So, with some academic theory and TJ’s practical experience, I started on the next trek, looking at companies that have experimented with the PWYL model. I found a few that piqued my interest (note, none were service based businesses):
  • Panera’s “Pay what you like” model for their Community Cafes.
    • Customers are given a receipt that shows full retail price of their food.
    • Since the cafes are nonprofits, a donation can be made for the food in an anonymous donation box. They accept cash only.
    • Bottom Line: 20% leave more money and 20% leave less. 60% pay what is on the receipt.
  • Roller coaster experiment with PWYL.
    • Focuses on selling photos to individuals after they have ridden on a coaster. One coaster offers a traditional PWYL model the other will give money to a charity based on what the individual pays for the photo.
    • Bottom Line: Individuals will pay a higher fee in a PWYL model if a charity is attached.
  • Game Proun PWYL experiment:
    • Proun game was provided to customers with the PWYL model. Yes, some could pay $0.
    • Bottom Line: PWYL model was great for the exposure and generating buzz around the game, but not for the money (he said it was good money for a hobby, but not for a full time job). PWYL continues but with a lower limit set at $1 rather than $0.
  • iPad Stylus PWYL with Kickstarter experiment.
    • Used Kickstarter (which is a way to generate funds for a project by offering rewards to the funder, read more at Kickstarter’s web site) and PWYL.
    • They clearly defined some key parameters: wanted $50,000 collected by 3,000 people (about $16.67 per person). If the project was fully funded, the iPad Stylus would cost $25.
    • Bottom Line: iPad Stylus was fully funded.
After mulling these around my head a bit and wandering through the Wikipedia site and Freakonomics site, I found myself yearning for more. Still, here are a few of my thoughts:
  • It’s disappointing that research and documentation on service based businesses using a PWYL model is lacking. I would love to see some academic research as well as some practical application of the PWYL model in service based businesses. Thanks to TJ for being so willing to share her results with me. It’s a start! I wonder if there is more research that I just haven’t found?
  • The “internal reference point” for a client has me thinking. Even those that were successful, in the mind of the seller, had set a reference point for the client. For example, Panera gave a receipt to the consumer. The iPad Stylus had base price of $25 and with Kickstarter gave a lower price of $16.67. And the software game has now set a lower limit of $1 rather than $0. This probably take the stress out of the process of figuring out the worth from the consumers perspective. But, how would one tackle this in a service based business?
  • Attaching a charity to the price seems exploitative, but it seems to work for the product in the roller coaster experiment. Might there be a way to do this but in a non-exploitative feeling way? I wonder….
  • I can’t work for free… that still keeps coming back to me. While I love the idea of changing this model to fit the compassionate model of Database Sherpa, I wonder if it’s possible. Could I be trying to do something that just isn’t possible?
I still need to do more digging around to find more resources and read more information. I feel like the process with trying this model will be:
Read idea -> Think about it for Database Sherpa -> Experiment -> Learn -> Try Again
This iterative process may help in defining the proposal process at Database Sherpa… the story will unfold as the business grows in compassion.