Are you an entrepreneur, investor, team member, or executive of a small business/ startup who is feeling the pain of being stuck in perpetual ‘almost-ready-to-release-but-not-quite-there-yet’ mode?
A few years ago, I was.
I learned (the hard way), what was standing in the way of us being able to release, to launch, to get out there and hustle!
I want to save you from having to learn the hard way, by sharing my lessons learned.
If you want to learn what things are holding you and your team back from releasing that money-maker project, read on!
Three main reasons you may be having trouble releasing your product and gettin’ your profits on:
1) Chaos (i.e. Lack of framework)
2) Authority Ambiguity (a.k.a Too much access to the product development team)
3) Perfectionism
Let’s break these down:
1) Chaos – or Lack of product development framework
I’m all for flexibility.
In fact, flexibility was one of the key things I highlighted in a recent presentation to my local PMI (Project Management Institute) chapter on how to achieve project success.
But before you can be flexible with your process, you need to have a solid working knowledge of it.
(To illustrate this, check out slide number 14 from my People over Process presentation. The one with the cool aikido move where one guy flips another guy in the air!
Note: For access to the presentation, use the sign up form in the sidebar!)
In the presentation, I introduced the concept of Shu-Ha-Ri, which you can read more about in Martin Fowler’s blog, as well as on Alistair Cockburn’s site.
Basically, there are 3 levels of learning/practice, with Shu being the very first, most basic level, and Ri being the highest.
Once you reach the Ri level of mastering a certain skill, you are able to effectively modify or adapt it while still achieving your desired result.
In a newly formed organization/team, there is a need for a certain structure and/or framework. This structure can be ultra-lightweight while still providing the roadmap to follow for building and releasing products/projects, and ultimately, MAKING $$$$.
Solution 1: Ensure you have someone in your organization who has experience and knowledge in different product development processes.
This person should have enough experience to be able to modify and adapt processes as needed for the organization and team, leading to successful release!
2) Authority Ambiguity (a.k.a Too much access to the product development team)
Open-door office policies and flat company structures are great.
They foster open communications, leadership at every level (because people don’t feel “managed” by other people in closed-off offices), and transparency.
However, too much manager and executive access to the product or software development team can become a problem for a couple of reasons:
- Conflicting directives: Who does the team listen to? The product development manager, or the charismatic CEO who, inspired by a great conversation or article, may drop by the product development team and throw out a “We should do THIS!”? (Leaving the team to wonder: Does that mean we’re supposed to BUILD that feature? Or was it just an idea?)
- Distraction: It’s tempting in a startup environment to want to question what’s happening and what the progress is at virtually every minute of the day, but this quickly becomes an impediment for the team.
Solution 2: Put an effective project leader in the right place at the right time, and allow her to be the buffer (when needed) between the team and management.
This creates more focus, productivity, and clarity of direction for the team. (And gets that product out the door!)
3) Perfectionism
You’ve hired the best of the best.
The people that know more about what they’re doing than you ever will. You know that combined, their potential is limitless.
But together, you’re still struggling.
That’s because the best of the best do not accept anything less than perfection (or close to it!). They know that if they spend 2 more hours, 2 more days, 2 more weeks on that feature, they can get it just right.
The secret here is realizing: You don’t have to be perfect. At a certain point, the returns you get from perfecting something are not worth the effort required.
Someone needs to help guide the team towards accepting what’s “good enough”. This can happen at 3 different stages of the project or product development:
- When defining the product features (i.e. up-front)
- When writing test cases and acceptance criteria for the features
- When reviewing test and/or demo results
Solution 3: Empower your project leader to challenge the definition of “good enough”.
Make sure to evaluate the benefits gained from adding features and functionality vs. the cost of doing so.
Your turn! Share with us:
What are your pain points as a team, startup, or small business? Which of the above solutions do you think would make the biggest impact on your project team?
