(Photo courtesy of https://unsplash.com/photos/3IVOgGIBsM0)
I recently had a (great) idea for a product. In my head it made perfect sense – a way to make it easier for people building presentations to get instant help from a trusted freelancer. Surely many people would be excited to try it out.
The idea went from sketched-out prototype to tech exploration to see if it was possible to execute the thing I was thinking about, and two things happened. First, two very smart people asked whether this is a problem that anyone has, and whether I had any data to prove the size of the market. Second, I realized I hadn’t done enough work to move from idea to execution.
“Of course,” I said, sharing market validation stats and thinking about channel partners. But then it hit me – I hadn’t yet taken the fundamental step to validating the market need by hand with no tech investment and no real effort spent. Ideas are a dime a dozen until they have some traction.
And it made me consider the optimal way of moving from idea to idea++, or taking the first next step toward validation. “Paper prototyping,” – the effort to simulate the experience of building product without actually building that product – is useful when combined with tests to establish demand.
In this case, what was needed was a plan to ask people (ideally those I don’t know) to state that 1) they needed help with presentations and 2) that they are willing to pay other people to solve that problem.
One way to test that would be to use an existing site where people request freelance assistance (let’s say Fivvr, Upwork, or similar) and put up an ad for services. The responses to this ad would give one set of signals for demand. Then, the type of work that resulted might help me determine whether the initial hypothesis is worth more thinking. And third, the initial revenue would give clues to the potential profitability of the idea.
Do I know whether I have a great product idea? Not yet. The next step is to validate whether presentations made “good enough” are sufficient for most people, most of the time. If that’s the case, on to the next idea, until there’s a bit more signal that this one is more than a momentary aha!
Imagine you are selling a new drink (perhaps in a new category) and you’re competing against Coca-cola. You’ve invented a nootropic brain drink that helps you stay calm and alert while coding, and it has a pleasant natural fizz to it. It might even be an unusual color like purple. Taste tests from prospective customers have been successful and the effects bear out from your claim – coders love it! Continue reading “New things are easier to sell when they seem familiar”→
I mean the kind of team that people and alumni talk about years later. I’m talking about a team that produces results, leads the market, and is the kind of team that spawns other great teams. It’s hard to produce these kinds of results once, so it’s all the more remarkable when the same team produces another high-performing team (and highly correlated to success in the new venture)
In my career, I have been on great teams, and also participated in not-so-great teams.
Here are a few things that great teams do that mediocre teams do not do:
Great Teams Focus Their Efforts
In a startup (or really inside any company) there is always too much to do and almost always not enough time and resources to do it. Great teams build a culture where people focus on the next best thing they can do to improve the company, and make it easy for people to work together to gain results. For example, when you cut a lightly used feature and take the time to improve an existing feature, you are lowering the surface area of your product and helping the whole team to feel better about the quality of your software.
Mediocre teams work on many projects at once and never ship. On these teams, someone always claims credit for doing the work instead of giving kudos to another team member to congratulate them on a job well done. Mediocre teams endlessly add features without taking the time to ask customers whether the existing features meet their needs.
Great Teams Identify and Amplify Team Strengths
On a great team, it’s easy to find specialists. They are busy doing what they do best – not struggling at tasks they do the worst – and producing strong results. Some of the specialists have a specialty of getting other people to make decisions, push themselves to do new things, or to reduce the overall quantity of work to produce higher quality work. Great teams form around individuals who have strengths the whole team can use. These teams ask “how can I help?” to each other rather than saying “I’m too busy – can you ask someone else?”
On a mediocre team, it’s hard to determine what anyone does well, because everyone is meeting with each other in the same meetings. There is no time for work during the work day, because no one comes prepared to discuss items at meetings, and people spend the meeting time multitasking and doing the work they could not complete in their previous meetings. Mediocre teams leach away the strength of their individual specialists by creating an environment where no one knows how to make a decision and where no one feels empowered to ask for that decision.
Great Teams Are Resilient
Having a great team does not isolate you from conflict. Great teams are effective at meeting conflict head-on, discussing the problem, finding a solution, and then moving forward either by “disagreeing and committing” or by genuine consensus. These teams are resilient because during times of trouble team members lean on each other’s strengths and find solutions to seemingly intractable problems.
Mediocre teams fall apart or descend into chaos during stressful situations. There are few things more disappointing than thinking you’re on a great team, encountering a stressful situation, and then realizing your team is rather mediocre. Instead of the support you get from a great team, on a mediocre team it ends up being every person for themselves.
Great teams are hard to find.
I recently joined the team at Kustomer because this is a great team solving a hard problem in an important market – CRM for support customers – and I wanted to be part of that effort. So far, working at Kustomer feels similar to the atmosphere I shared with some of the team members when we worked together at Assistly. We work hard, we play hard, and we are building a business centered on our customers. But what makes a team great?
Great teams sometimes form by themselves and sometimes are made. People know a great team when they experience it. Great teams do not last forever, because culture is hard. When you get the band back together, it doesn’t always work. But when it does, it’s amazing.
Kustomer is a great team. We are crushing it. That doesn’t mean we’re always right – it means we are going after a great market with proven technology expertise, deep domain expertise, and a kick-ass attitude.
If there’s nothing else you remember from this post, spend 15 minutes writing down your goals for your next project so that you explain them better to the people who matter. The simple act of writing down your goals is a powerful organizer for you, the people you are interacting with in your project, and the people you want to benefit.
Build the Big Picture
When you paint the picture of a problem, a high-level reason why that problem needs to be solved, and a proposed end state that is a great start. That statement doesn’t explain the How, or the resources and tactics you use to get from “project not done” to “project done” within a known amount of time and effort.
So spend a few minutes writing down the ideal state and how you want to get there. Your way will probably be different than mine, which follows a template of prompts. STOP and go do that, then come back.
It seems silly to focus on such a small goal, because knowing what you’re going to do for your project, feature, or idea is obvious.
Test that theory the next time you feel you have alignment on “what is my project” or “what is my feature” by asking someone else to tell you what they think your project is, what benefits it will deliver, and to state the goal you’re both working to achieve.
When the goal of the project, the definition for that project, and the benefits of that project are clear(er), it’s a lot easier to know where to start.
What does this look like in practice?
Consider this example: “Build a new web site Widget.”
If you know: “we have never introduced a thing like this before onto one of our pages,” you might want to test that results differently to make sure there is no required dependency in your environment.
If you know: “we use these things all of the time, and this is a new instance of a thing we do already,” your comfort level will be increased.
And if you know: “we have already described the ‘look and feel’ of this widget in the fonts, colors, and information architecture of our website, for example page xyz,” you will have made it much easier to know what the thing is that you are building.
Stating the benefits for your project helps you to understand the measurement you’ll need to quantify these benefits. Then, find the measurement as it stands today. Yes, it does seem elementary to find a baseline, and you need one to prove that something change. If there is no baseline, state your assumptions and move on.
Getting Started …
In the spirit of a brief solution, I’ll keep this post short too. When you’re ready to make your next project better, set a timer for 15 minutes and write the overall goal, 3 things you want to do toward that goal, a statement for how you will measure your progress, and any questions you have about the project. This simple exercise makes it easier to share what you’re doing, how you’re thinking about it, and how to make progress.