Tell me one thing: Where’s the value?

Where’s the Value?

As we march on with the continued development of our excellent Unity solution, there is one question that keeps coming up from customers: Where’s the value in your solution? It’s a standard question posed by any customer – and by the marketing and sales teams – because they want to know why anyone should shell out their capital for something that isn’t always tangible at first blush. Value isn’t easily defined, but equally importantly, defining value is a misleading question to ask.

Value Is What You Want It To Be

As I am in product management, here’s my take on the term value. Value is defined by who the user is you’re trying to help and what they want to hear. Or not hear. One person’s value could be time-saving and for another it’s how much did the solution cost compared to other similar ones. In other words, what am I getting for my money?

Essentially value is fluid, it changes with time and with the audience who’s looking at the solution. Unfortunately pricing and perceived value are often equated, and that’s tough to overcome. Particularly for software solutions because no one wants to pay for anything. It’s tangibility is virtually nil, and making use of it usually means change, and change is pain. So where’s the value?

How Do You Make Something Valuable?

There are two ways to deal with this value dilemma:

  1. Price it high and come up with a value prop that you hope and pray will mesmerize the potential buyer to pry open a rusted-shut wallet
  2. Speak to resolving pain points and deal with the value prop later

No matter what, as a product manager, I have to come up with a price and a value prop or they’ll fire me and hire an intelligent chimpanzee who wears a hat. However, to me that is secondary. I can always come up with something that shows you your ROI is ‘X’ dollars over ‘Y’ years. That’s the perceived value argument.

But in reality, I’ll get better customer response and eventually sales if I discover the pain points and resolve them. Like a human body, when you’re freed from pains, you can focus on what matters and be productive. The difficulty is that pain is relative. No one likes pain (at least in business) and everyone’s is different. Sales, engineering, development, administration all have unique pains, so my job is to find out specific pains, and alleviate them. In this case with software.

As for my Unity product, all we do is focus on alleviating business pains but it’s hard to put that into a monetary value.

Additionally, the question I have to ask is, regardless of the value, is your pain big enough that you need this solution? I am assuming it does otherwise we wouldn’t be doing this development. From a marketing/value prop perspective, I have to find a way to make it obvious that you don’t want to let your pain get so bad that you’re desperate for help. Let me help you before you’re hooked on consulting fees, physiotherapy and meds.

So where’s the value, you ask? Let me answer it this way. Focus on removing the pains first, the deal with the value later. Freedom from business pain is perhaps the greatest value.

Unity Webinar – Recap on Project Management Best Practices

7 Best Practices

Hi all,

We just had a great series of webinars on a cure for your project management woes. It was fun and educational! (The dream scenario of every teacher and parent.) We covered some points of contention we face in the world of wireless network deployments. Not least of which are the dreaded “4 Pillars of the Project Apocalypse” – SoftwareHardwareRegulations, and People!

OK, maybe apocalypse is a little strong, but wireless network deployment projects are really complex. So many interested parties, so many things to consider, so many things to organize and so little time. You need to make the best of what you’ve got. Using Unity, for example, is a great place to start to leverage all the brilliant designs and mobile files you’ve gathered to deliver the finest QoS your customer will be delighted with, of course.

But beyond that, I want to briefly list the 7 best practices we covered:

  1. Store Project Assets Centrally; Make sure they are in a structured format with classifications and a search function, so you can access them later when you want to leverage what you already did. This way you save time, effort and get projects done more quickly. And don’t forget, those project assets are your IP and they also cover your posterior in case you have to prove something to an official. So cherish them dearly.
  2. Build a ‘Diamond’; Make sure the key influencers inside AND outside your organization talk to each other on a regular basis. Sounds simple, but making it happen is hard. It’s worth the effort when questions come up.
  3. Frequent Checkpoints; Have quality checkpoints, but don’t micromanage. Validate the completed work done using objective KPIs before moving on to the next stage of the project. Fewer long-term costs and repairs that way.
  4. Know Your Regulations; Actually, don’t just know what the regs are, have a go-to person who is the point person for all questions. Not several people, just one. And any documents relating to the regulations should be stored in — you guessed it — your central project repository.
  5. Think Bigger Picture; Don’t focus solely on the budget and timeline of the project. Know how strategic a project is to your organization and the importance it has to the execs. Make sure the key stakeholders (see point #2) are informed at all times, and especially execs – they HATE surprises!
  6. Parallel and Sequential Tasks; The short version, parallel tasks are task silos that can go on without any dependence on another task, whereas sequential tasks have dependencies. For those, use a workflow engine. Way easier to manage projects.
  7. Plan for Iterative Loops; Like the sun rises in the east there will be amendments and fixes from the final design to the actual as-built. But you can make this less painful by leveraging that Diamond I mentioned in #2. Also, plan to have your RFE and field techs hang around for a while after the “final” design, if they need to make changes and retest.

Now wasn’t the helpful? I think it was.

In future episodes of the Unity Blog, I’ll explain in greater detail what to keep in mind when you roll out your next project with iBwave tools & solutions. I promise you’ll profit from it – if not financially, then you’ll at least be able to impress your friends at parties with sage project management advice.

Unity Webinar – A Cure for Project Management Woes

Hey iBwavers,

We have a great webinar. It’s all about the frustrations and mismanagement of projects and what you can do to sleep a little better at night.

Here is what we will talk about:

  • The cost of improper planning – case in point: The Montreal Super Hospital
  • The cost of using a project planning tool that doesn’t quite fit the bill
  • The most common stumbling points in a wireless network project and how to avoid them

I, your erstwhile product manager, will go through some of the trends and horror stories, and give some advice on the experiences we have gathered from our many years working with our customers and the challenges they face.

I’ll also explain how we built our Unity solution to handle these issues.

Watch Webinar »

Looking forward to sharing the knowledge!

Exit mobile version