Join the Vewrite Beta
Vewrite, project management tailored for technical writing teams, is launching soon. Make sure to sign up for the waitlist so that you can be notified when the product launches.
Open WebsiteHow do you get your product to market and ensure that it matches a market need? This is the problem that every founder, every team, and every company of every size encounters when they attempt to develop a product.
If you’re building a product, you likely have some vision for what it is and you need some plan for how to get it into the user's hands. You must also be aware of the fact that your product doesn’t exist in a vacuum. At the end of the day your product’s success is entirely dependent on whether or not you’ll find users, partners, and a market for it. Typically this is called Product-Market fit. I’m not a huge fan of that terminology because it insinuates that you and your team are somehow not an integrated part of the market, but are adjacent to it. But, what can you do? That’s what it is called.
Finding Product-Market fit can be a frustrating, demoralizing, and fruitless effort if you do not have the right feedback cycle to support the decisions that you make. Alternatively, it can be a fast-paced, exciting ride that changes your career and your professional life. It's up to you and your team to decide which of the two experiences you'll have and isn't a simple happenstance.
You’re probably not going to get it right the first time, so your process needs to be built around getting there in as few steps as possible.
I've put together some thoughts that I use to give form to the concepts that I turn into products. Following that, I talk about what I think is the right process to mold your unformed idea into something that fits people’s needs.
Hopefully these ideas can help you and yours have a better time getting your house in order as you ship your great new thing.
Figure out your product’s answer to “Why?”
At the foundation of a software product is the deceptively simple question of “why are we doing this?”. Fundamentally, that question and its answers are what sets good products apart from bad ones.
If you can competently, coherently, and confidently express why you’re building what you’re building, then you’ll be able to decide what you want to build and who you’ll want to build it for.
Getting Started
Define your product’s vision. This doesn’t have to be exact, and in my experience will change over time as you speak to people who are using your stuff. The idea here is that you have to have some current product vision in your head so that when you have some tough choice to make, there is some guiding principle that shines a light on the right way forward.
Roughly outline your software product and its feature goals. Roughly is the key word. You want big, bulky sets of concepts and not detailed, fully planned out sets of features. Remember that you shouldn’t be making assumptions, and that if you invest tons of time figuring out every detail, you’ll end up having to throw a lot of that work away.
Explicitly state how your product supports your business via revenue. This is of course only relevant if your product’s continued existence hinges on that revenue. If not, carry on. Revenue generation as part of your product ensures that you can keep building, and your users can keep using.
Explain who you're trying to sell to. If this isn’t clear from the get-go, you’re probably just building something for yourself with the hope that someone, somewhere out there, will want it to. More often than not, this isn’t true and you’ll burn a lot of time (and money) building something that has no future.
If you've been reading this and thinking, wait, isn't this part of my business plan? What does this have to do with my software product? That is the core point that I'm trying so hard to make in this section: there isn’t really a divide between the software that you build and the business that runs it. They must be deeply intertwined so that when you define features they are based on some user need, some partner requirement, or some business goal.
Your answers to Why? guide your product and keep you from getting lost in the weeds.
Get some product out there
You can’t iterate if you don’t have something to build off of. A blank page is the hardest thing to overcome.
Defining your first iteration
This is the thing that holds back founders and startups the most because the boundaries for an MVP are very hard to define.
Too little and your product doesn’t make much of a splash.
Too much and you spend too long building and either run out of money or the market moves on and you’ve missed your opportunity.
Err on the small side
If you aren’t sure, build less and deploy faster. It’s better to be feature poor, than to waste time building the wrong things.
Once you have some product released to the market, you need some feedback. There are a myriad of ways that people do this (or worse, don’t do this), and there are a bunch of caveats and gotchas that we should consider when getting feedback.
Talk to your product’s users
From my perspective, there are two ways to go about understanding what you’re supposed to be building.
Experience has taught me to prefer the latter one because it has a built in iterative and reactive product cycle. But, let's start with the more common formal process so you have something to compare it to. Formal Interviews (bleh)
Interviewing is the commonly accepted methodology within Product Management (and UX) processes in most large companies.
Formal Interview process
Product Managers (or Owners, or UX specialists) produce a set of questions to ask users of a product. These specialists target areas for improvement and try to illuminate user pain points. Intermittent interviews are set and run periodically, as time allows.
The feedback from the interviews is then digested by those specialists and fed back into the product cycle.
My core gripes with this methodology are that
There are many assumptions built into it that narrow user feedback down
Interviews happen only intermittently and feedback is not always immediate accessible by those who need it most
In trying to create a consistent process, you will often miss important edge cases, user groups you didn’t think of (and engage with), and product problems due to predetermined expectations.
It is a fundamental truth that you can’t think of everything, and so your process can’t include it all.
At the end of the day, this process is really about insulating teams from users to ensure that there isn’t internal disruption from external forces. Designers and engineers do not have direct contact with the users that they are impacting through their decisions.
This means that those teams can work in peace, but it also often means that they are working on the wrong things for the wrong reasons.
Embedded Knowledge
The second way of determining what you are supposed to build is something that I call “embedding”. I take the name from how journalists embed with troops as they deploy to combat. These journalists aren’t active in the fight but are down in the dirt and exposed to how things play out in real time. They see the truth.
Embedded Knowledge process
The concept behind embedded knowledge is that you should be directly interacting with your users on a day to day basis, either through your support mechanisms, or through some community discussion platform.
The information that you, your designers, and your engineers gather directly from those interactions is fed directly back into your product cycle so that you can determine each insight’s level of importance and impact.
The core value of this methodology is that it isn’t intermittent, but is instead constant. The feedback that you are getting from the market is always the most up to date, and the most relevant to your product and to your business.
If you’re embedded in the community of users who are using your product, then the teams who build it are not directly insulated from the users that are impacted by their decisions. This is a fundamentally different way of working which creates a level of personal responsibility that is missing in more formal methodologies.
I’m sure that you can see the value of this latter way of working.
Caveats
Don’t believe everything you hear
This is tricky to write about because it is not a straightforward do-this, do-that kind of thing. Understanding what is valuable feedback versus what is not is an intuitive sense that a team builds up over time.
It’s dangerous to take every bit of feedback at face-value, both from external users and from internal stakeholders. It is a balancing act that can be difficult to manage.
Users do not always know what they actually need, and their complaints my only be symptomatic or hints that point you towards a more holistic, comprehensive solution.
What is valuable for one user may not be valuable for any other user, which means that if you satisfy that one user, you have used up resources which may have benefited more users. Bang for your buck is a very real consideration that must be respected when choosing what to build next.
Business development, marketing, and other stakeholders within a company may drive revenue and traffic, but they should not be the sole drivers of a product. Their specific view of what is valuable is skewed towards their goals. These goals may or may not align with user’s needs or your product vision. Stay focused.
Start Iterating
Lack of clarity inevitably leads to unnecessary redesigns, loss of users, reduction in revenue, missed business opportunities, wasted development efforts, and unhappy teams.
Fortunately, the best way to gain real clarity is a matter of communication with those that actually use your product and a proper product process that takes feedback and turns it into something better than it currently is.
Build something simple, Talk directly to your users, Carefully digest feedback, Iterate.
Then, do it again.