Getting Feedback: Making It More Attractive

Before Google practically destroyed the word ‘beta,’ people used to go about getting feedback on their work through closed testing, tight feedback loops, and other forms of getting work in front of others in a closed group of people to see how a sample of users would interact (or just simply react).

Movie production companies still do this – they test audiences: They see how they react to certain actors, certain endings, certain takes, and all that fun stuff.

In software, we still do that, but we throw words around like alpha and beta to the point where they have no real meaning anymore. At one point in the life of projects, alpha testing was solely for an internal group of testers, then beta testing was when it was open to a small group of people in the public in order to gather more feedback and to shake out bugs. Then there were release candidates followed by the final version (or the 1.0).

After that, we rinsed, and we repeated it.

Now, far more people have access to alpha-level software, and projects usually remain in beta as a way to excuse any problems that may occur during the course of using the application. After all, it is beta, so it’s use at your own risk, right?

Anyway, I could say a lot more on this, but I digress.

Getting Feedback on Your Work

The reason that I bring this up is because regardless of what terminology people have opted to use, I think that it’s important to have people test your projects, review your work, edit your copy and or your writing (I could stand for some of that, I think :), and so on.

I’ve done this with previous projects and it’s worked out well, and I’d argue that anyone else who has done the same for their work would say the same.

As I mentioned a couple of weeks ago, I’ve a number of things sitting in my project pipeline and though I’ve been working diligently that work for some time, I’m finally getting to the point where I’m getting the shop setup so that the various products can actually be offered.

The Pressware Shop

a snap of the upcoming pressware shop

And though it’d be easier to throw together a few landing pages, add some copy, and then launch, I think the end result can be far more effective if there are a number of different people reviewing, testing, and helping put all of the collateral together.

Or Your Can Settle For Second Rate

To be clear, this is not a call for beta testers, reviewers, or anything like that, but it’s more of a statement on the importance of getting feedback. Right now, I believe that we’re in a state of a bit of a gold rush as it relates to WordPress products – be it themes, plugins, applications, services, and on.

Because of that, people are launching things with half-baked websites, poorly produced videos, and less than stellar impressions – we run our mouths about how we want to build “handcrafted” or “world-class” products, but it comes off like we’re using broken hands or some other class of planet to create the first impressions our potential customers will see.

We – as people involved in the economy of WordPress – need to stop that.

Despite whatever criticism it may receive, we know

  • WordPress is an amazing platform
  • Individuals and companies are doing tremendous work on the project and on projects build on top of the platform
  • There’s great educational efforts going on around the core application
  • It’s only going to get better over time

Sure, I could say more, but with all of the above said – and even known – why do we cut corners in terms of launching our products, services, and so on without taking the time to gather feedback from others?

This is something that I’ve been guilty of, so this isn’t the pot calling the kettle black, either.

Anyway, if your primary argument has something to do with being “first to market,” then that’s weak – I’d rather be at the tail end of the market with the absolute best launch and product and customer experience than first to market with the exact opposite.

I’d venture to bet most of you would, as well. Besides, first to market just defines the benchmark for  the competition, doesn’t it?

You Should Be Getting Feedback

And I know: Not everything that everyone works on is some type of product.

Some times its a design, it’s a product, it’s a service, it’s a talk, and so on. It’s something and it’s worthy of feedback Regardless of what it is that you’re working on, I urge you to seek feedback. Constructive criticism is still criticism so it can sting, but it keeps you better in the long run.

We can help make WordPress more attractive for customers by first getting feedback rather than launching half-baked projects and hoping for the best.

6 Comments

Very wise, solid advice. I’ve mentioned before how arduous, lame and sometimes even unnecessary-feeling the front-end work and prep that goes into launching a product/service is, but it’s vital to the project’s longevity. Measure twice, cut once. The patience and diligence saves so much time on the back end that will definitely be needed for proper support, marketing, updating, etc… and doing the research, testing and tweaking is all part of a proper marketing plan. I see a lot of people that recommend to “just get it out there–it doesn’t have to be perfect,” which is foolhardy. Of course, it doesn’t have to be perfect, but it needs to be ready, presentable, not half-baked as you recommend, and you may even discover there’s not even a decent market for the product/service at all, which having the knowledge of earlier than later will definitely worth the relatively minimal time and effort.

    Measure twice, cut once.

    Bingo. That’s what it comes down, too. It’s hard because it prevents that excitement that comes with a launch as it pushes the date further out, but it’s so worth it – if you can swing it.

Thanks for the timely reminder, Tom. I’ve been working on my next plugin for a very long time, and am starting to get impatient and tempted to cut corners.

And even when I’m done, then I’ve got to tackle documentation, building a website for it, and marketing and promoting.

On those I do need help!

Be nice if you’d consider an article on that stage of the business, and the hows and wheres and whos of it. For example, as a one man op, how do you get help with those things when you don’t have an income stream yet to pay for help? Where do you go to find that help? How much time and money should go into those? Like, you can make things ultra-schmick, but then that costs you either a lot of your time or your money. At what point are you over investing in those areas?

With this sort of stuff, usually I just fly by the seat of my pants and hope things work out!

    Thanks for the timely reminder, Tom. I’ve been working on my next plugin for a very long time, and am starting to get impatient and tempted to cut corners.

    I think this happens to the best of us, Chris, but we’ve gotta train ourselves to pull back from doing that. For what it’s worth, I’ve experienced the exact same thing before.

    I hate the feeling, but it does get easier to manage.

    On those I do need help!

    Find a team of people – trust me, it sounds crazy (and maybe it is), but there are people who are willing to work in the open source space for compensation other than money. It can be done, and it can include people who are of the utmost integrity.

    For example, as a one man op, how do you get help with those things when you don’t have an income stream yet to pay for help? Where do you go to find that help? How much time and money should go into those? Like, you can make things ultra-schmick, but then that costs you either a lot of your time or your money. At what point are you over investing in those areas?

    I just posted a very long article – arguably my longest – about some of this, but I’ll see if I can’t revisit this more in the future once I take care of some other things first.

    Added it to my backlog of content to tackle in the future, even :).

Leave a Reply

Name and email address are required. Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>