Superb deconstruction of the meaning behind “minimum viable product” from The Macro.
I spent much of the summer of 2015 in Paris working with an agency’s development team that had seriously gone off the rails. I was the client and part of my mission was to assess the true capability of the assembled team.
This is a conversation I had with a very nice developer who the agency claimed was a senior front end developer:
“That menu is wonky and the UI lags horribly. Why don’t you optimise or rewrite it?”
“I see. How’s your CSS?”
“Well, it could be better. I don’t really work on that here.”
“Are you better with the backend? How’s your PHP?”
“I want to learn more about PHP.”
“Ah ok. Well, what happens when we have a problem like this with the menu?”
“A tech lead who reviews our work from time to time, but he isn’t available until later in the week. I’ll ask the business unit director when we can speak.”
This developer was clever and friendly, but clearly not able to work on a complex project independently.
The agency fundamentally failed this developer by leaving him adrift with no meaningful support. Absent agency-side leadership, I stepped in and rallied the team – and made sure support mechanisms were put in place when I returned home to London.
Developers don’t need to know the JS hotness of the month, but they do need to possess knowledge of the fundamentals, know what they don’t know – and, most importantly, be flexible and know how to find the answers.
There’s a brilliant episode of the Shop Talk podcast that considers “The State of Front-End Dev” and how mixed-skills teams can work, “what it means to be a senior developer” and some of the challenges in defining just what should a front-end dev know. Essential listening to anyone building products in 2016!
Google provides superb machine-learning. Apple contributes gorgeous devices and (relatively) seamless user-centric experiences. Companies like Dropbox, Amazon and, intriguingly, Upthere offer unlimited, always-available storage.
But we don’t yet have the software or the infrastructure that knits everything together.
This is such a thrilling time to be working toward building interoperable, cohesive, compelling experiences for myself, my friends, my family, my community.
In Part 1 we began by asking ourselves some guiding questions to challenge our initial assumptions. In Part 2 we defined our vision and mission, products or services and how we’ll know when we have succeeded.
Now we want to survey the competition – see where they are, what they’re doing – and why. A typical competitive analysis methodology :
- Who are they?
- Who are our competitor’s users?
- How does our competition reach their users?
- What’s the product?
- What’s the product’s position in the market?
After we’ve done our homework about our competition’s customers and devised a proper SWOT analysis, we will want to know more about how products are used.
At work I recently completed a study of 20 different sport and news websites, in particular the editorial strategy of responsive web views vs app home screens and their respective navigational schemes.
Have a look at following examples of two very similar, yet subtly different products. What conclusions do you draw from the following questions:
- What are the “jobs to be done” by this product?
- How do our competitors minimise effort?
- How do our competitors monetise?
Remember, just because a cool new feature or service exists in a competitor’s product doesn’t mean it’s appropriate for your product.
It’s important to know why a feature exists, because that’s the only way you’ll be able to determine if it’s the right fit for your product and help achieve your commercial goals.
The job, not the customer, is the fundamental unit of analysis for a marketer who hopes to develop products that customers will buy.
Clayton Christensen on “What Customers Want from Your Products“
Often when I tell newly met acquaintances how I make my living this statement/question arises – “I have an idea for an app (or website, etc) – tell me how do I make it?” Where to begin? Perhaps with a quick overview of my previous experience. Over the past 14 years I’ve made a wide array of products and services, monetised through advertising, subscription and mixed revenue models :
- Streaming video portals
- Screen savers
- Advertising creatives
- Flash-based games
- Marketing microsites
- Educational assessment
- Breaking news, live video & video-on-demand sites and apps
Despite differences in scale and diversity, all of these products began by answering a series of “guiding questions”. These aren’t the classic “five whys”, but instead help lay the foundation for further development of your idea or proposition :
- How would you describe this in 60 seconds?
- What problem does it solve?
- What is the service?
- What is the opportunity?
- Who are the competition?
- What is our competitive advantage?
- How will we monetise this?
- What is required to deliver this?
- What don’t we know and how will we find the answers?
If you’re able to quickly answer these questions, you’ll be well on your way toward making a commercially viable product or service.
This will be the first in a series of articles discussing how one conceives of, constructs, delivers and maintains a digital product. It’ll be a blend of commercial considerations, project management, product delivery and technical development.
So how do you know if you’re doing a good job? After all, when you really look at what’s being decided on one end and produced on the other, it might look like a PM is doing nothing at all. In most cases, this invisibility is a good sign. There are a few other tells.
“A big one is that the founders ping you directly without CC’ing other people. They just trust you to follow through and they know your team trusts you to be a good channel of information back and forth,” Jackson says. Communication skills are paramount. ‘One sign of a great PM is that other people get quiet when they start talking. A lot of PMs talk too much and spend time on things that aren’t important until people start tuning them out. If you see a PM talking and everyone else stops talking and listens, you know they are pretty good.’
You’re also a good PM if your absence is noticed by the best engineers on your team. “You want them to ask ‘What would that PM do or say if she was here?’ You want the best people to value your opinion that much and know you have the technical prowess to meaningfully contribute.”