Scott Sehlhorst

Member for

13 years 10 months

Scott Sehlhorst is an agile product manager, product owner, and business analyst and architect. He helps teams achieve software product success by helping them build "the right stuff" and "build the right stuff right." Scott started Tyner Blain in 2005 to focus on helping companies translate strategy and market insights into great products and solutions. You can read more from Scott at tynerblain.com/blog.

Company

Tyner Blain

Job Function

Consulting

Industry

Business Services - Consulting - Non-profit

Interests

Business Analysis

Process Improvement

Requirements

Country

United States

Scott Sehlhorst

Scott Sehlhorst is an agile product manager, product owner, and business analyst and architect. He helps teams achieve software product success by helping them build "the right stuff" and "build the right stuff right." Scott started Tyner Blain in 2005 to focus on helping companies translate strategy and market insights into great products and solutions. Read more at tynerblain.com/blog.

All Articles by Scott Sehlhorst

All Stories by Scott Sehlhorst

	Managing "But We Need This" Requests from StakeholdersProduct owners are constantly beset with a continuous stream of requests for the urgent, the important, and the marginal. The assumption implicit in such requests is that there is room for more of the "but we need this" requests to be filled.
	To Estimate or Not to Estimate—That Is the QuestionIn the agile community there is a movement called “no estimates”—where people are challenging the value and validity of estimating the work required to develop software. Scott Sehlhorst looks at the different perspectives of those who challenge estimation.
	Creating Software from a List of Things? Then Don't Call It AgileThere are two ways to think about scope—a list of things to be done or a list of goals to accomplish. As long as scope is defined as a list of things, then your project process is not agile, even if your team is using the mechanisms of agile development within the code creation cycle.
	Why Being Simple Is Better Than Being SimplisticProduct managers know that a product needs to be simple to succeed in a market. Although being simple is a product virtue, being simplistic can be a product vice. Scott Sehlhorst evaluates why it's better to create a product that is simple—not simplistic.
	Why a Product Strategy Is Not a Product PlanStrategy is important not just because you want to be intentional but also because strategy makes you more efficient. Strategic activities ensure the intended product is the right product. Scott Sehlhorst looks at why a strategy is not a plan; instead, strategy guides planning.
	Stewardship in Agile Software Architecture and DesignSoftware architects typically don’t own the products that individual teams are creating, yet they help define a cohesive approach to developing the products and are often responsible for defining how different products interoperate. Scott Sehlhorst looks at the idea of architecture stewardship.
	The Outside-In Approach to Product PositioningEarly on product positioning helps drive focus and clarity for the team and allows a stakeholder to approach funding decisions from a strategic perspective. Scott Sehlhorst highlights some outside-in approaches to product positioning and their benefits.
	User Story Mapping—Goal-Driven Backlog DevelopmentWhen product managers plan what product releases will include, the goal is to deliver value for the users. Every release of a product should make it better than the previous release. User story mapping is a technique for assuring that each release or iteration makes the product tangibly better.
	Are You Experiencing Product Manager Insomnia? What should be keeping you awake is what keeps your customers awake. Remember to be market-driven and to focus on the problems that your customers value—and are willing to pay to solve.
	The Right Way to Split User StoriesOne of the key techniques in the mechanics of agile software development is the splitting of epics into stories. Scott Sehlhorst highlights examples of ways to split user stories and discusses the debate between breadth-first and depth-first development.
	Hiring Technology Product Managers: The LatestScott Sehlhorst looks at an analysis of how companies are posting requirements for hiring new technology product managers in the US—including the trend of placing more importance on domain experience than product management experience.
	Become a Better Product Manager: Your Project Deserves ItBecoming a better product manager is something you never stop doing. As you get better, your work will improve, your satisfaction with your work will increase, and opportunities to do even better work will come. Scott Sehlhorst sums up how to invest in becoming a better product manager.
	Take the High Road When Creating Product RoadmapsOne of the mistakes made when crafting a product roadmap is building a roadmap that schedules all the features and functions you plan to build. That’s taking the low road. You want conversations with customers to be focused on the problems people solve with your product. That's taking the high road.
	Business Analysts: Your Team Is Your Customer, TooThe most important customers of business analysts are the team members that create the solution. Secondary customers of the business analysts are stakeholders, sponsors, and end-customers of the product. Scott Sehlhorst explains what it means to think about your team as your customer, too.
	Validating Requirements with Given-When-ThenWhen identifying requirements, it can be really tricky to develop a good understanding of how software should behave. Scott Sehlhorst looks at the Given-When-Then approach and how it allows teams to combine the benefits of incremental development with the benefits of getting it right the first time.
	How to Make Products People Love Scott Sehlhorst explores how to make products people love and focuses on Marty Cagan's ten tips presentation at MindTheProduct 2012, London's first conference for product teams. Key points include product discovery, not building what customers want, and building what customers need.
	Why Documentation Is Important in Agile, TooShould agile teams relax the requirement that user documentation be updated during each sprint? After all, the Agile Manifesto prefers working software over comprehensive documentation, so shouldn’t we be able to relax that requirement? Scott Sehlhorst explains why his response is "absolutely not."
	Moving from Customer Focus to Market FocusBeing customer focused is supposed to be a good thing. But if you are focusing on a collection of individual customers and you’re not focusing on a market of customers, you have the customer part down, but you forgot the focus. Scott Sehlhorst offers guidelines for becoming market focused.
	Behavior-Driven Development: The Outside-In ApproachBehavior-driven development (BDD) is a software development practice that is utilized by many agile teams. BDD is an evolution of test-driven development but with an important distinction—it is outside-in. Scott Sehlhorst provides a business analyst’s understanding of BDD.
	The Product Canvas: A Complementary View The product canvas, when used with a business model canvas, provides similar benefits to the product owner that the business model canvas provides to the product manager. Scott Sehlhorst examines the product canvas and the business model canvas and how the two tools can be used together.
	Story Roadmaps—Product Vision That Paints a PictureA product roadmap tells the story of what you’re going to do with your product. It is a manifestation of the vision of what you’re trying to do and why. Scott Sehlhorst explains how best to communicate the product roadmap with your team and the product's stakeholders.
	Using Kano Analysis to Define Your MVPKano analysis is a great tool for prioritizing the capabilities that you build into your product. It provides a great framework for competitive analysis, comparing products in the context of what actually matters to users and not just a list of checked and unchecked boxes.
	From Acceptance Criteria to Acceptable ProductUsing acceptance criteria to define an acceptable product works all the way up the stack from clarifying what the development team is being asked to do, to understanding what the users really need, to defining the minimum viable product that allows the company to achieve its goals.
	Bad Product Backlogs Are...Bad Agile software development teams are getting caught on the merry-go-round of incremental product improvements and are failing to create innovative products. Are bad product backlogs to blame?
	Offshore Agile DevelopmentWith the increasing trend toward outsourcing aspects of software development, Scott Sehlhorst analyzes how this trend affects companies and their agile development teams.
	How (and Why) You Should Split User StoriesThe Scrum process is built around the process of implementing user stories. Many teams struggle with the challenge of knowing how to split user stories so that the individual stories have atomic value and are properly sized.
	How to Start a Business Model Canvas The business model canvas is an informal presentation of a formalized description of why a business will succeed, built around the value proposition of the business. We explore the core of the canvas, examine the value proposition, and provide tips on how to start a business model canvas.
	Tips for Starting (and Ending) a Process AnalysisWithout boundaries, a process analysis could go on forever. Adapting things learned from working in agile software development, Scott Sehlhorst provides tips for starting—and ending—a process analysis.
	There's No Such Thing as a Freemium LunchThe freemium business model—in which some users use the product for free, and others use it for a fee—can be appealing. To succeed with the freemium model, you must first acknowledge that a revenue plan is not a business plan and then decide if it makes sense for your bottom line.
	Just-in-Time Requirements AnalysisAll requirements are built on some sort of hypothesis. Just-in-time requirements analysis embodies the idea that you form your hypothesis as late as responsible—not as late as possible.
	Busting Agile Prediction MythsWhen first hearing about agile processes, you might think that teams using an agile process cannot provide estimates, predictions, or commitments about what they will deliver. But, you can be agile and still manage risk and commit to a subset of what you predict.
	Understanding Context When Designing Products for UsersWhen designing software, you must look beyond simply knowing the goals of your users. It's far more useful to understand the context in which the product will be used.
	Are Your Requirements Flying Blind?Of all of the requirements a stakeholder says "must" be done, how do you know which ones "should" be done? Connecting the project vision and goals to the requirements can help your team decide.
	Fat Companies and Lean RequirementsHistorically, large companies relied on waterfall methods, but many of these organizations could benefit from a little "agile mojo." Applying aspects of hypothesis-driven development to requirements writing can help cut through the bureaucracy and put your team on a leaner path.