Episode 8 – Watershed Distillery

I had a great time talking shop with Greg Lehman, Owner of Watershed Distillery.  His story is an inspiring story about how plans can change along an entrepreneurial journey. Being open to change and letting others help you is key in so many of the stories this season, but I think I saved one of the best for last, I hope you enjoy it as much as I did!

Episode 7 – Phoenix Consulting

Episode 7’s Toni Teague Bell is a writer, producer, on-air talent and founder of Phoenix Consulting Company, a performance consulting firm that designs and facilitates trainings, retreats and symposia.

Working with corporations, non-profits and universities, Toni has inspired thousands. She sat down with me to share some wisdom and advice from her 18+ year entrepreneurial journey – enjoy!

Episode 6 – Shatter

GiveBackHack is an event near & dear to my heart, and it’s also where Sarah Woods accidentally started her company, Shatter. Based on a powerful idea of how to help women shatter the glass ceiling, the Shatter story may just inspire you to turn your passion into a business, too.

 

Episode 5 – Robinson Legal Group

An entrepreneurial lawyer specializing in entrepreneurial law, that’s Episode 5’s Demetrius Robinson, founder of Robinson Legal Group. Demetrius talks about his love of his job, his enthusiasm for helping entrepreneurs, when he started hiring specialists, and when you should reach out to a lawyer on your own entrepreneurial journey.

Episode 2 – BLK Hack

Episode 2 features Branden & Bruce Jones, the co-founders of BLK Hack, a social enterprise network that helps African American entrepreneurs and people of color grow, nurture, and scale their businesses by providing access to an engaged and supportive entrepreneurial ecosystem. Hear how BLK Hack fills a need that they themselves encountered on their entrepreneurial journey and how they’ve grown in the years since their first business pitch.⠀⠀⠀⠀⠀⠀⠀⠀⠀

Episode 1 – Haven

Episode 1 premiers on SEPTEMBER 9th!
⠀⠀⠀⠀⠀⠀⠀⠀⠀
I’m thrilled to announce that my first guest on the very first episode of Greater Together is my dear friend Melissa Blackburn, Co-Founder of Haven. It’s hard to believe we met almost a decade ago, while we were both still working for a company, instead of for ourselves. Haven Collective is a GREAT co-working space on Riverside Drive, and they will be expanding to downtown in just a couple months! Hear what she has to say about her entrepreneurial journey and lessons learned along the way. ⠀⠀⠀⠀⠀⠀⠀⠀⠀

Reading Technical Proposals

A client of mine recently received a proposal from a software developer, and asked me to look it over and let her know if I thought it was “ok”.  As far as proposals of work from an independent developer go, it was pretty good.  It had a long list of bulleted items that would be included, was broken into 4 phases of work, with a separate cost estimate for each phase.  The one thing it was missing, at a high level, was a delivery timeline estimate (would phase 1 take a week? a month?).

But the first thing I noted, in my feedback to her, was that it was very much written both by and for the developer.

I found that it was really good at detailing a bunch of technical tasks I was sure she didn’t specifically request. In some cases, it even detailed some tasks I wasn’t sure she’d actually want performed. Conversely, I recalled several specific features she wanted developed, that I didn’t see listed.

Incomplete proposals are fairly common, it can seem tedious to write out every little detail (and also feel pretty thankless before you’re getting paid), so I asked her, “Do you feel like he truly understands what you want?” and gave her a couple small examples of where his proposal didn’t match my understanding of the product she was trying to get built. One of her responses is what prompted me to write this post.  She said:

“I didn’t see that feature in the proposal either, but I wasn’t sure. I thought maybe he included it, but just in technical terms I didn’t understand”

To me, that’s not “ok”. Before signing off on any proposal, or any other contract, formal or informal, you should always feel confident that you understand what it says.

So what’s a non-technical reader supposed to do?

Know what you want

You probably have a good idea what you want, and it’s ok that you do not know every detail involved in creating it, that’s why you’re hiring someone.  Being able to spell out what you want may seem easy, but actually this is the bulk of the hard work you’ll need to do. “I need a website” is not sufficient, you need to be very clear about your vision. You need to go into as much detail as you can, and you need to understand any decent developer will likely still have good questions when you’re done. If you get stuck describing, in your own words, what you want, it’s ok to describe it by using examples – as long as you can be specific about what about each example you want (and what you don’t).

Get really practical. List out all the things you can think of, even little things, and even though it may be tedious: “show my phone number on every page”, or “customers should be able to purchase in USD with Visa or MasterCard, but not American Express or Discover”. List out everything you don’t know: “Can I use the merchant account I got from my bank to accept money online, too?”, or “Will the logo I bought for my letterhead work for the iPhone app icon?”

Ideally, you’ll have written all that down before you ask anyone to bid on the work.  That way, when you get back a proposal or estimate, you can look for all the things you asked for.  It’s actually a good sign, in my opinion, if the person bidding on the work asks for a copy of your list in electronic format to use to start their proposal.

If you don’t see some specific thing you wanted listed anywhere in the final proposal, but you know it was in your list, you’re in a great place to start a conversation about it.

Ask Questions

Even talking amongst themselves, technical people often say things like, “I don’t see feature X, can you point it out to me?” in a discussion about whether a written proposal truly covers everything. My client was worried that might be offensive to her developer, but it’s nothing to shy away from.

Best case, they simply forgot to include it, or summarized the information in a way that wasn’t clear to you. That’s easy to resolve, you just ask them to add it in or make that section clearer. Worst case, they intentionally omitted it, but even that can be a huge positive. If they intentionally omitted it, the reason may be because it’s beyond their skill set, or they disagree with it, or they believe it contradicts something else you requested. Any of those reasons can (and should) lead to a good conversation, and is certainly information you’d rather have now, than after a portion (or all) of the work is complete.

No matter how good your list was, how many questions you ask, or how much you ask to be rewritten for clarity, you should not feel bad.  Even people whose whole jobs are writing specs (or designing software) forget things, contradict themselves, and ask “obvious” questions from time to time. The end result, and whole point, is a proposal that you feel confident you understand. You should be comfortable you understand what you’re going to get, and the proposed amount of time and expense it will take, just like any other decision you make about your business.

Recommended Reading: The One Thing

If there were only one book I would recommend to business owners, “The One Thing,The Surprisingly Simple Truth Behind Extraordinary Results” is it.

This book clearly walks through what focus is, why it is important and how to achieve it in practical terms. As a bonus, it’s a quick read!

The specific questions laid out in “The One Thing” aren’t exactly the ones I’ve used through the years, but they are good and the entire approach is so similar to what I’ve found works through the years, that as I read it, it made me wonder if the authors had been inside my office (or mind).

I read it on loan from the Columbus Library, but of course “The One Thing” is also available from Amazon. (I have not been compensated in any way for my review of this book, and those are regular links, not affiliate links)