What Your RFP Process Really Delivers


I work on 20Skaters, ThreeFortyNine, DemoCampGuelph and a few others. My vanity site is brydon.me.

Personally I’ve had a long standing policy to not respond to unsolicited Requests For Proposals, known as RFP’s. In the early days, I couldn’t give you a sound reason for my avoidance. I’m sure my main reason was that I didn’t feel confident I could craft a worthy response to your 64 page fancy-pants RFP with its budgets, timelines, stakeholders and other terms that had me reaching to wikipedia. Or maybe my gut was telling me to steer clear?

Eventually we tried responding to a few in earnest. While we’ve only done that a few times, the results have been consistent. We’ve earned 0% return on all our RFP work to date.

My policy to date remains that I don’t respond to unsolicited RFP’s unless I’m able to have direct conversations with the key stakeholders in the RFP process. Why? Simple, in some cases RFP’s are not what they appear to be. They are rarely a level playing field. Often decisions have already been made, or the vendors have been narrowed, and the RFP process is a corporate requirement intended to present the illusion of an unbiased process. That means you’re lucky if anyone even reads that response your team spent weeks or months crafting.

Even in the case of a truly open, democratic RFP process, it’s very premise is in direct contrast to how I tend to work. All of my best clients over the years have been relationship based. That means we courted each other first, we put time in, met each other, talked about our world views etc, maybe had a few drinks, shared some meals. Only after all that did we end up at “hey, we should work together”.

I’m not alone. Alan Armstrong of Eigenworks writes that “unsolicited RFPs can consume precious team energy, and our win rate is essentially zero.  I made the tough decision a long time ago to focus my team’s efforts on clients where our relationships are more direct”.

So here’s the rub. If your company is currently relying on RFP’s to find your vendors, you need to reconsider that approach. I can’t imagine that your company does NOT want strong vendor relationships. By choosing the RFP route to find and select vendors, you are immediately eliminating myself, Alan and a glut of other potential vendors who have all come to the conclusion that RFP’s are a waste of their team’s time.

How DemoCampGuelph Saved My Business

Nathan Snelgrove

Nathan Snelgrove is the founder of Wildfire Studios, a creative firm in Guelph focused on everything from graphic/print design and brand development to photography. He loves movies, music, and fine whiskey.

Last December, I was in a rut.

I own a creative firm called Wildfire Studios, and I was pretty sure it was going under. Not because I was out of money, but because I was out of clients.

I had a half-decent roster of clients that I enjoyed working with. They liked me. They were all international and under one conglomerate client. The problem was, the conglomerate decided to shut down all my clients on January 1st, 2014.

I knew I shouldn’t have had all my eggs in one basket, so to speak, but I couldn’t escape that rut either. I knew I needed local clients, but I also knew that local clients are a chicken and egg problem: unless you have one, you’ll always need one. Firms with international clients often smell like scams — even if you’re running a perfectly legitimate business, there aren’t many ways for professional clients to verify that claim.

dcgIn our world, it’s not about what you can do, but iwho you know. In that sense, DemoCampGuelph is a godsend.

I attended DemoCampGuelph 22 in October, and walked away having met a ton of cool people from a bunch of amazing startups. What struck me the most about the event is its lack of pretence and pretension: everybody was there to learn from each other and get to know one another. We all wanted to broaden our support system.

I followed one woman I met that night on Twitter. She had her own development company, and she worked on mobile apps. When she retweeted a tweet about one local firm looking for an outside designer to do some app prep work, I quickly sent off an email.

I really needed anything to get by, and this gig was perfect for the short time period. It was enough for me to get through January. The design work was really some short-term marketing work for a multinational corporation called ProMinent Fluid Controls Ltd, which in itself was an amazing opportunity. The Canadian division of the company has an office located in Guelph, which means my local client roster can develop.

One opportunity leads to another, though, and ProMinent started hinting that they were looking for some long-term marketing help. They didn’t want full-time, but they wanted client services they could depend on to produce results. I went through about a month of getting to know the people and prepare my work, and I got a contract to handle their advertising. We’re putting together the first of this year’s six product campaigns this month.

Thanks to DemoCampGuelph, my firm is more than just a creative firm. Wildfire Studios isn’t just about graphic design, photography, or creative copywriting. I’m now handling the advertising for the Canadian division of a multinational. To me, this is the new start that I desperately needed.

Thanks to DemoCampGuelph, not only do I still have a job and a business to call my own, but I have one of the best jobs in the world. And for that, I couldn’t be more grateful.

DemoCampGuelph 24 will be held on May 28th, please register if you’re joining us.

Let’s Reinvent The NDA, For Entrepreneurs.


I work on 20Skaters, ThreeFortyNine, DemoCampGuelph and a few others. My vanity site is brydon.me.

Do you sign Non Disclosure Agreements(NDAs)? In general, I’m told most funding folks do not. I have signed many but I do so cautiously. There are many opinions on signing and not signing.

I tend to view it as a red flag when early stage projects request that I sign an NDA before we’ve met, or even decided to work together. My concern being that they are over valuing their ideas. The red flag isn’t that their ideas aren’t amazing, it’s that in over valuing them, they are likely failing to knuckle down on customer discovery, pre-sales, idea extraction and all the other important parts to validate the business opportunity.

When people say ideas are worthless, it’s because they are. Otherwise you could post your idea on eBay and sell it. It’s also why I correct people when they say things like “20Skaters is a great idea”. I respond that it’s no longer an idea, it has customers, revenue….

To be clear, no one is saying that you don’t require awesome ideas. What they’re saying is that ideas are worthless without execution! A great idea is table stakes, so ante up and get executing!

If you have the choice between an ok idea that you can execute on versus a killer idea you can’t get to a market, always take the ok idea. As you execute, the core idea will shift, grow, and morph. You don’t want to be known as an ideas person, you want to be known for your ability to execute!

What I always say is please steal my idea, provided you can deliver on execution! I’ll happily move onto the next item on my list. How about this for the new NDA?

In taking on this idea, I promise to do everything in my power to execute on this. I will not bask in the glow of the idea, I will take it to market. I will grab it by the collar and drag it across the finish line. I am the person best suited to execute on this idea in the fashion it deserves, not let it languish and die a slow, lonely death protected away from the world.




Bug Free Software


I work at Boltmade and 20Skaters. I mostly write Ruby, HTML, CSS, and JavaScript. I hate timezones.

Recently the company I work at, Boltmade, was undergoing a rebranding. Naturally we looked at the websites of other software development companies to see what they were saying about themselves. To me, one site stood out. 8th Light says in their company principles that, “we take responsibility for the correctness of our code by testing it thoroughly. We do not tolerate preventable defects”. Going further, the blog post that accompanies this says, “if we make a mistake, we’ll fix it quickly—for free. It’s that simple”.

What strikes me most about this is that it’s surprising at all. Why shouldn’t this just be how software development is done? Why do we just accept that all software will have bugs? It is true that is technically impossible to remove all possible bugs from a piece of software. But an over acceptance of this is leading us to create software with far more defects than should be acceptable.

It may be impossible to remove every final last bug, but if I’m doing my job correctly, I can guarantee that the things I know about will work. An article I read recently (Bug Free Software? Dream on) stresses the impossibility of getting rid of all bugs. In particular one phrase bothered me. The article says that “developers play whack-a-mole” with bugs. This bothers me because in that game, the moles come back out of the same hole some undetermined time after you knocked them down in the first place. In a way, it’s a perfect description of the experience of many developers. They fix one bug over here, rush to put out a fire over there, and when they come back they find that somehow the first bug has come back again. However, there is no reason developers should have to play this game. Proper testing should ensure that when you fix a bug it stays fixed.

The only way someone can deliver on their promise of bug free software is to test it thoroughly. I don’t really care if that means you clicked every path through the system, and tried every use case. If you’d rather do that over writing tests, be my guest. Just remember you’ll be doing it every time you change anything. As for me, I’ll write the tests once and have them catch things for me from then on.

So why don’t more people do this? Well, testing is hard. It takes time to learn how to test, it takes time to setup the tools to test, and it takes time to run the tests (much less time than it would to click through every path in the system, although I would argue that almost nobody actually does this when they say they tested it manually). But that doesn’t mean it’s not worth it. Investing the time in this area will pay off. But if you don’t make testing a priority, figure out how to set it up, and ensure that everyone is running the tests, you won’t see any benefit. It takes buy in from everyone. If one person is over in their corner diligently writing tests and nobody else does, you will still end up with a fragile application.

AirBnB just posted a great article about how they went from, in their words, “a handful of brittle tests to a large, resilient suite”. There are some good pointers in that post on how to achieve the same thing. To me, there were a few important things that stood out:

  1. Change your culture to “make testing a first-class citizen”. As I mentioned, if nobody believes in it, it’s not going to happen.
  2. Avoid the pattern of “we know tests are important, but we’re too busy to do it right now”. If it’s important, it’s important. Do it.
  3. Make “the bar to writing tests…so low you can trip over it”. Make things easy and people will do them.
  4. And finally: “The important thing is to test all the f***ing time. Even when it’s hard. Especially when it’s hard.”

So how do you know if you should be thinking about tests? To me, the test for if you need tests (or more tests), is how comfortable you feel pushing a new build to production. Does it make you hesitate? Do you cross your fingers hoping things will be ok? Do you always do it early in the day so you can be around in case something goes wrong? If so, then maybe considering getting some more tests in there. Deploying shouldn’t be a scary process.

I’m happy to hear your thoughts, please leave comments below! I could ramble on this topic for a while but I don’t want to write a huge wall of text. I’m happy to continue the discussion in the comments or write a follow up post.

Hijacking the Pycon train

Chris Charles

I'm a software developer. I like to learn things. I run the ThreeFortyNine Beer Club, which is pretty fun. I recently built BeerTime, an Untappd client for the Pebble smartwatch.

In less than two weeks a bunch of Ontarians are heading to Montreal for Pycon, and they’re doing it in style. How much style, you ask? The most style. They have two dedicated train cars, one of which contains a bar.

I’m not going to Pycon, but I am going to be on the train.

See, Montreal’s not just for conferences. It’s a pretty cool town! With museums and culture and stuff! It also has a great pub scene, and I happen to be a bit of a beer nerd.

Beer taster at Dieu du Ciel!

Courtesy of Paul Joseph http://www.flickr.com/photos/sashafatcat/4052075222/ CC BY 2.0

So I’m going to Montreal with some people from my Beer Club, and we’ve decided to ride the rails with the Pycon folks. Many of us have tech backgrounds, and the opportunity to unconference with other tech people is too hard to resist. I’ll get much more out of the trip this way.

Here’s a short list of things I remember from my trip on the Startup Train two years ago:

  • I met a bunch of really cool people with whom I had great discussions about technology, business, and the environment.
  • I saw some pretty good presentations.
  • I found out why so many people love to travel by train.
  • I laughed a lot.

I expect to have an equally good experience this time around.

Do you love beer too? Food? Live music? Art? Fashion? Comedy? Do you have a background or an interest in technology? Maybe you should join us. You don’t have to go to Pycon. Ride the rails, spend a day (or two, or a week) in Montreal doing something you love, and come back.

It’s going to be a blast!

Software Developers….On A Train


I work on 20Skaters, ThreeFortyNine, DemoCampGuelph and a few others. My vanity site is brydon.me.

Our upcoming Python On Rails is having a bit of an identity crisis.

Is it a peer-based, on-train, mini conference for software developers, that happens to arrive in Montreal at the start of PyCon? Or is it a means of travel exclusively for PyCon attendees?

On The StartupTrain 2013

On The StartupTrain 2013

Our previous StartupTrains have proven that our on-train events have their own value, their own identity. We always have people on board who literally fly home the same evening we arrive in Montreal. They’re on the train just to attend our on train events.

For our Python On Rails train, we’ve already sold tickets to people NOT attending PyCon. We’ve also sold tickets to people who are travelling from Montreal, just to turn around and take the train back home with us.

Why would someone want to come on this trip and not attend PyCon?

  • You already know some other passengers taking the train and based on that, you know this train is going to be a blast.
  • You’re one of the folks we’ve talked to who intend to spend a few nights exploring Montreal’s brewpub scene. Yes you’re also involved in software so the train is just an awesome way to get to Montreal.
  • You’re looking for one of those unicorns they call a technical cofounder for your new startup. The chance to be locked on a train with awesome software folks is too good to pass up.

We’re in the heart of planning out our on-train events for this trip. There’s talk of xboxes and DemoCamp/Ignite style talks so we can learn what projects we’re working on while getting to know each other.

Get your ticket here, did I mention we have our own bar car??

A Train Full of Software Developers


I work on 20Skaters, ThreeFortyNine, DemoCampGuelph and a few others. My vanity site is brydon.me.

While it can be fun the first few trips, travelling for business and conferences generally sucks. It’s a necessary evil in order to get yourself to an awesome conference like PyCon. We’re hoping to fix that for a small group of people heading to PyCon in Montreal this year.

snakes on a train

We’ve chartered our own VIA Rail train cars with first class service and we’re filling them with the Python community to travel from Toronto to this year’s PyCon in Montreal on April 10th. Why wait until you get to Montreal to start meeting and collaborating with the folks in the Python community? Travel time is only wasted when you do it alone.

Book your ticket on the Python On Rails train now before they’re gone.

We’re still planning our on-train activities but suffice to say you’ll have a chance to meet a ton of great people like yourself while making the pilgrimage to PyCon. Our activities will be focused on getting you connected with our other passengers and we’ll have lot’s of time to socialize on our own private bar car.

The valuable connections made on our previous StartupTrain trips have resulted in new jobs, consulting gigs and even cofounders meeting and launching new startups together. Our passengers for this year’s Python On Rails are already getting to know each other in a private online space we’ve setup for them to collaborate before, during and after PyCon.

Founders Suck At Grammar


I work on 20Skaters, ThreeFortyNine, DemoCampGuelph and a few others. My vanity site is brydon.me.

So founders suck at grammar, or at least I do. We host a weekly event in our space that we named Founder’s Club. It’s a peer based group of individuals who are starting something, or about to. Actually a lot of members are in between startups as well. Ultimately our event is group therapy for those of us crazy enough to attempt creating something from nothing.

We’ve been running this event weekly for a few years now. It was only yesterday that a new member informed me that our grammar was painfully incorrect….

“Founder’s club: Brydon’s club, Brydon’s a Big Founder, other people are invited.

Founders’ club: Everyone’s club, a bunch of founders get together, Brydon is just the guy who founded the Founders’ club

Big difference! I think you mean the latter, but you use the former spelling.”

So let it be known, we host Founders’ Club events here! Our founders have customers and revenue but we let some other things slide….like grammar.

Roadmaps, Focus Groups, Personas and Other Ugly Crutches


I work on 20Skaters, ThreeFortyNine, DemoCampGuelph and a few others. My vanity site is brydon.me.

Have you ever created and maintained a Product Roadmap? It’s an excellent tool that allows a team, or the execs, to plot the precise path a software development team is heading. You then simply share the roadmap with the team and they start following the directions that will take them on their way to a successful product.

It’s pretty much identical to the way real roadmaps work. You and the kids sit down to plan the road trip down to Florida. Mom and dad, while consulting little existing tools or data, get out the paper and pen and sketch out how you’re going to make your way to the sun. Or wait, does that metaphor even apply?

What about focus groups and surveys, have you used those for product development? Customers always end up doing exactly what they said they’d do right? I’m assuming there were no leading questions in your surveys that lead people to tell you precisely what you wanted to hear, if only to just finish the stupid survey.

How are your personas these days? Do they live and breath? Are your personas so detailed and well written that your team feels like they haunt your offices?

The above are a few examples of tools used in software development in an attempt to guide the development of the product without having to talk to real people. That’s right, without talking to real customers! All of the above can play valuable roles in product development, however, they need to be kept in check.

As an example, surveys shouldn’t be used in place of speaking to real customers. Personas should be abandoned once you have real customers you can engage with, and talk to. A product roadmap is a terrible tool when compared with a development team who is deeply engaged with your real customers.

Use all the above tools and more but please, treat them like the crutches they are. Your goal is to develop your team and it’s connection with your real customers to the point where you can discard these crutches. You want your team running fast not hobbling along burdened by walking aids.

I’ll be digging into this a little more this evening at our weekly Founder’s Club. We typically have room for guests so if you’re interested in discussing this more, contact me about joining us at 8pm Wednesday night.

Ignite Guelph. March 11. Because you only turn 3 once.

Kyle Mackie

Educational Consultant. Community Builder. Technology Champion.

Ignite Guelph

Ignite Guelph is a celebration of geek culture in the Guelph area. At Ignite, presenters use their personal and professional passions to inspire the audience. The catch? They’ve got just 20 slides and five minutes to do it.

Ignite Guelph is part of a global thing. The first Ignite event was held in 2006 in Seattle, and since that time has spread to regular events in over 100 countries. We’ve done this in Guelph twice so far, and it was pretty great.

Check out some of the past Ignite Guelph videos to see how this all goes.

On March 11th, we’re cranking it up again, and it promises to be an inspired evening. Maybe you came in October and you want to come again. Maybe you haven’t been able to attend previously, and the now the time is right. Tickets go quickly, so you likely want to get on this soon.

Ignite Guelph is run by a team of fabulous volunteers, and supported by awesome local businesses and groups (including threefortynine). It couldn’t happen without them, or without you.

So thanks for that, and see you next Tuesday.