Mile Marker hosted our first webinar on creating technical product strategy for new products. Whether you’re a startup or small business, CEO Daniel Litvak’s tips are proven to help teams like yours save time and money on new product development. Check out highlights from the presentation below.
Connecting Your Tech Strategy to Your Business Strategy
Before you can outline a technical strategy for your product, your business goals have to be defined. If your ultimate goal is to get funding, then your technical product strategy needs to be built with that goal in mind. You may have heard of the 5 elements of a SMART business goal (Specific, Measurable, Achievable, Relevant, and Time-Based) – these principles apply to software development as well.
At Mile Marker, we help startups and small businesses not only develop new products, but establish a sound foundation for their business plan to bring that product idea to life. The pyramid above illustrates how we think about it: you have to build your tech strategy on top of product and business goals, not the other way around. When the inverse happens, we see companies struggle: they build too much tech, they don’t get enough user feedback early in the development process, and they don’t have the sales and marketing support to gain traction in the market. Your tech plan and tech team need to be in place purely to support business goals, or you won’t make it.
Product Strategy: How do you develop product goals based on business goals?
Stay focused on your MVP. When you’re outlining a product strategy based on your business goals, it’s important to stay focused on your Minimum Viable Product (MVP) – creating the minimum amount of features to satisfy early adopter expectations and validate your business concept. There are a lot of tangential terms like “Minimum Lovable” or “Minimum Desirable” products, but don’t get distracted by those - a viable product solves problems, and is therefore lovable or desirable. Bottom line: define what “minimum viable” is for your business, and stick with that to avoid bloating project scope.
Be user-centric in your problem solving. We love this quote from Michael Seibel, “You want to build your first version for customers who have their hair on fire.” The problem you solve has to be at the user level if your product is going to be viable. You can’t solve a problem at the societal or company level. Let’s use the example of seniors falling in an assisted living facility: we can all agree it’s a serious problem that we all wish could be solved. But in order to solve that problem, your product can’t focus on the big picture, it has to focus on one individual “user” within it – would it be the senior patient, who has trouble remembering to alert staff when they want to get up from their bed or chair? Would it be the nurse, who can’t always be in the room with their patient? Would it be the adult child of the senior patient, who can’t stay with them at the care facility? You have to clearly define the user and their problem before you build a product.
Define and prioritize your product features. Once you identify a problem, you can start to define and prioritize features. At Mile Marker, we use a scoring system that helps us prioritize high-value, low-effort features first that align with a business’s core value. It keeps us from building unnecessary features, which is key – unnecessary features can distract users and dilute their feedback.
Create user flows. We ask our clients to do this first without us, and then with us, as an exercise. Most people tend to focus on answering the question “What does the user do once they’re logged into the product?” but we think it’s just as important to start at the beginning and answer, “What triggers the user’s initial action to sign up for the product, and log in to use it?” and answer the final question, “How does the user know when they’ve solved their problem and are ready to log out?” The whole flow from start to finish matters.
When your product plan is bigger than your budget, strategize. This happens all the time and it’s a natural part of learning about your target market and user, and the problems they face. Your vision for the product will evolve and grow, and inevitably the ideas your team comes up with will be bigger than your budget. You have to evolve the features on your platform at a sustainable rate, and that means you have to earmark certain features for later investment. This is where a product roadmap comes in — document your plans, keep the entire team informed (developers, sales, business, marketing, and ops), and once you gain more funding, you’ll know what to build next.
How to Create a Technical Product Strategy
Architectural decisions have to be prioritized based on business goals. Knowing what components to prioritize will come from your product strategy, but some will also emerge from business strategy: understanding your market share, your value prop, etc. This is why it’s so important to keep your developer and business teams aligned. For example, if you’re a generative AI company, the look and feel of your interface will not matter to users as much as your generative AI model, data set, and capabilities. Your developers need to be able to answer: which features will build the value of the business? Those come first.
You will also need to make decisions to maximize your resources. Resources doesn’t just include capital, it includes people – you need to determine how best to use their time, whether it’s the engineers and scientists, or the executive leadership. Keep them focused on their domain expertise, because their time is valuable. You’re not likely to get what you’re looking for if you ask them to contribute to QA testing, for example.
Make decisions about standards and security earlier in the process than you think you’ll need to. Standards and security can vary widely depending on your business type, from B2C or B2B, and even within enterprise environments. Yet no matter what type of business you’re in, standards and security have to be a part of the conversation from the beginning because it sets the foundation for what you build. If you don’t consider those decisions early on, you may have to rebuild later and at a significantly higher cost. For example, many of our clients are looking to get SOC 2 certified to ensure the proper data protections are in place for them and their customers. When we know that a SOC 2 certification is a goal from the beginning, we can build with those standards in mind and ensure that all of the site infrastructure, architecture, designs, and documentation are up to snuff. HIPAA standards would be another example for products in the healthcare industry.
Do not skip analytics. These are often overlooked in the beginning, but logging and analytics are integral to validating your business purpose and goals. An MVP has to include analytics if you want to gain the funds to scale it into a full product, because you have to be able to demonstrate to investors that you’re meeting (if not exceeding) KPIs in order to gain their trust and their funding. Analytics are also a crucial component to getting real, measurable user feedback beyond just dialogue. It’s one thing to have a conversation with a user about what they think of the product; it’s another to actually be able to see, click-for-click, how they interacted with your product features.
Minimum Viable Presence
Returning to our Business-Product-Tech pyramid, your business goals are the foundation of your technical strategy. Every architectural decision has to be made because of a business goal if you want to succeed. Your Minimum Viable Product has to be in service of your business, and you have to define what “minimum viable” means, not just for the product, but for your whole business. In business terms, it might help to think of it as Minimum Viable Presence, where the product is just one part of it. You need a minimum viable sales process, minimum viable marketing, minimum viable operations and customer support. All of the other parts of your business need to be accounted for when establishing your product and technical strategies, if you want it to gain traction in the market and succeed.
There was much more to Daniel’s webinar presentation, including tips on how to select the right integrations and third party solutions for your platform, how to choose between open source and hosted solutions, how to know when to hire internally versus outsourcing, and insights on creating a solid working relationship with your developers. If you want to view the full recording, start here. Want to join future Mile Marker webinars? Sign up for our monthly newsletter to be the first to hear about upcoming events and other resources, like our forthcoming eBook.
About Mile Marker
Mile Marker is your strategic partner for agile software development. Created for founders, by founders, we offer strategic software at startup speed. We specialize in aligning your technical work with your business goals through collaborative planning, offering a multidisciplinary development team, and ensuring ongoing support for your software. If you’re searching for a software development company or need a technical partner, start the conversation with an introductory call.
Comments